[jira] [Updated] (CASSANDRA-13299) Potential OOMs and lock contention in write path streams

2017-09-07 Thread ZhaoYang (JIRA)

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

ZhaoYang updated CASSANDRA-13299:
-
Reviewer: Paulo Motta

> Potential OOMs and lock contention in write path streams
> 
>
> Key: CASSANDRA-13299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13299
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benjamin Roth
>Assignee: ZhaoYang
>
> I see a potential OOM, when a stream (e.g. repair) goes through the write 
> path as it is with MVs.
> StreamReceiveTask gets a bunch of SSTableReaders. These produce rowiterators 
> and they again produce mutations. So every partition creates a single 
> mutation, which in case of (very) big partitions can result in (very) big 
> mutations. Those are created on heap and stay there until they finished 
> processing.
> I don't think it is necessary to create a single mutation for each partition. 
> Why don't we implement a PartitionUpdateGeneratorIterator that takes a 
> UnfilteredRowIterator and a max size and spits out PartitionUpdates to be 
> used to create and apply mutations?
> The max size should be something like min(reasonable_absolute_max_size, 
> max_mutation_size, commitlog_segment_size / 2). reasonable_absolute_max_size 
> could be like 16M or sth.
> A mutation shouldn't be too large as it also affects MV partition locking. 
> The longer a MV partition is locked during a stream, the higher chances are 
> that WTE's occur during streams.
> I could also imagine that a max number of updates per mutation regardless of 
> size in bytes could make sense to avoid lock contention.
> Love to get feedback and suggestions, incl. naming suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13299) Potential OOMs and lock contention in write path streams

2017-09-07 Thread ZhaoYang (JIRA)

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

ZhaoYang updated CASSANDRA-13299:
-
Status: Patch Available  (was: Awaiting Feedback)

> Potential OOMs and lock contention in write path streams
> 
>
> Key: CASSANDRA-13299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13299
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benjamin Roth
>Assignee: ZhaoYang
>
> I see a potential OOM, when a stream (e.g. repair) goes through the write 
> path as it is with MVs.
> StreamReceiveTask gets a bunch of SSTableReaders. These produce rowiterators 
> and they again produce mutations. So every partition creates a single 
> mutation, which in case of (very) big partitions can result in (very) big 
> mutations. Those are created on heap and stay there until they finished 
> processing.
> I don't think it is necessary to create a single mutation for each partition. 
> Why don't we implement a PartitionUpdateGeneratorIterator that takes a 
> UnfilteredRowIterator and a max size and spits out PartitionUpdates to be 
> used to create and apply mutations?
> The max size should be something like min(reasonable_absolute_max_size, 
> max_mutation_size, commitlog_segment_size / 2). reasonable_absolute_max_size 
> could be like 16M or sth.
> A mutation shouldn't be too large as it also affects MV partition locking. 
> The longer a MV partition is locked during a stream, the higher chances are 
> that WTE's occur during streams.
> I could also imagine that a max number of updates per mutation regardless of 
> size in bytes could make sense to avoid lock contention.
> Love to get feedback and suggestions, incl. naming suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12014) IndexSummary > 2G causes an assertion error

2017-09-07 Thread Stefania (JIRA)

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

Stefania updated CASSANDRA-12014:
-
   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 3.0.x)
   4.0
   3.11.1
   3.0.15
   Status: Resolved  (was: Patch Available)

Committed to 3.0 as ae88fd6c79b066f12ad76c2c1bfc1620d86bdbc5 and merged upwards.

> IndexSummary > 2G causes an assertion error
> ---
>
> Key: CASSANDRA-12014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12014
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> {noformat}
> ERROR [CompactionExecutor:1546280] 2016-06-01 13:21:00,444  
> CassandraDaemon.java:229 - Exception in thread 
> Thread[CompactionExecutor:1546280,1,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.maybeAddEntry(IndexSummaryBuilder.java:171)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.append(SSTableWriter.java:634)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.afterAppend(SSTableWriter.java:179)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:205) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {noformat}
> I believe this can be fixed by raising the min_index_interval, but we should 
> have a better method of coping with this than throwing the AE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-09-07 Thread stefania
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/260475d0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/260475d0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/260475d0

Branch: refs/heads/cassandra-3.11
Commit: 260475d0f2b1f9a8344a3cfb38f6766c9241b52e
Parents: 5dcb354 ae88fd6
Author: Stefania Alborghetti 
Authored: Fri Sep 8 12:43:30 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:43:30 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 123 +++
 3 files changed, 179 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/260475d0/CHANGES.txt
--
diff --cc CHANGES.txt
index 75d9bd6,f4360be..23e6c8b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,14 -1,4 +1,15 @@@
 -3.0.15
 +3.11.1
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
++ * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
   * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
   * Better handle corrupt final commitlog segment (CASSANDRA-11995)
   * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/260475d0/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
--
diff --cc test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
index f3757a0,ad08ba0..ab0486d
--- a/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
@@@ -45,14 -44,126 +45,137 @@@ import static org.junit.Assert.*
  
  public class IndexSummaryTest
  {
+ private final static Random random = new Random();
 -private final static IPartitioner partitioner = Util.testPartitioner();
++
 +@BeforeClass
 +public static void initDD()
 +{
 +DatabaseDescriptor.daemonInitialization();
++
++final long seed = System.nanoTime();
++System.out.println("Using seed: " + seed);
++random.setSeed(seed);
 +}
 +
 +IPartitioner partitioner = Util.testPartitioner();
  
+ @BeforeClass
+ public static void setup()
+ {
+ final long seed = System.nanoTime();
+ System.out.println("Using seed: " + seed);
+ random.setSeed(seed);
+ }
+ 
+ @Test
+ public void testIndexSummaryKeySizes() throws IOException
+ {
+ testIndexSummaryProperties(32, 100);
+ testIndexSummaryProperties(64, 100);
+ testIndexSummaryProperties(100, 100);
+ testIndexSummaryProperties(1000, 100);
+ testIndexSummaryProperties(1, 100);
+ }
+ 
+ private void testIndexSummaryProperties(int keySize, int numKeys) throws 
IOException
+ {
+ final int minIndexInterval = 1;
+ final List keys = new ArrayList<>(numKeys);
+ 
+ try (IndexSummaryBuilder builder = new IndexSummaryBuilder(numKeys, 
minIndexInterval, BASE_SAMPLING_LEVEL))
+ {
+ for (int i = 0; i < numKeys; i++)
+ {
+ byte[] randomBytes = new byte[keySize];
+ random.nextBytes(randomBytes);
+ DecoratedKey key = 
partitioner.decorateKey(ByteBuffer.wrap(randomBytes));
+ keys.add(key);
+ builder.maybeAddEntry(key, i);
+ }
+ 
+ try(IndexSummary indexSummary = builder.build(partitioner))
+ {
+ assertEquals(numKeys, keys.size());
+ assertEquals(minIndexInterval, 
indexSummary.getMinIndexInterval());
+ assertEquals(numKeys, indexSummary.getMaxNumberOfEntries());
+ assertEquals(numKeys + 1, 
indexSummary.getEstimatedKeyCount());
+ 

[2/6] cassandra git commit: Avoid assertion error when IndexSummary > 2G

2017-09-07 Thread stefania
Avoid assertion error when IndexSummary > 2G

patch by Stefania Alborghetti; reviewed by krummas for CASSANDRA-12014


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae88fd6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae88fd6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae88fd6c

Branch: refs/heads/cassandra-3.11
Commit: ae88fd6c79b066f12ad76c2c1bfc1620d86bdbc5
Parents: d34f479
Author: Stefania Alborghetti 
Authored: Fri Sep 8 09:33:20 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:37:45 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 121 ++-
 3 files changed, 176 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4302fdf..f4360be 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -95,6 +95,7 @@ Merged from 2.2:
  * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
  * Nodetool upgradesstables/scrub/compact ignores system tables 
(CASSANDRA-13410)
  * Fix NPE issue in StorageService (CASSANDRA-13060)
+ * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
 Merged from 2.2:
  * Avoid starting gossiper in RemoveTest (CASSANDRA-13407)
  * Fix weightedSize() for row-cache reported by JMX and NodeTool 
(CASSANDRA-13393)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java 
b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
index 6110afe..e3006b3 100644
--- a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
+++ b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
@@ -25,7 +25,9 @@ import java.util.TreeMap;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
+import org.apache.cassandra.config.Config;
 import org.apache.cassandra.db.DecoratedKey;
+import org.apache.cassandra.db.TypeSizes;
 import org.apache.cassandra.dht.IPartitioner;
 import org.apache.cassandra.io.util.Memory;
 import org.apache.cassandra.io.util.SafeMemoryWriter;
@@ -36,6 +38,9 @@ public class IndexSummaryBuilder implements AutoCloseable
 {
 private static final Logger logger = 
LoggerFactory.getLogger(IndexSummaryBuilder.class);
 
+static final String defaultExpectedKeySizeName = Config.PROPERTY_PREFIX + 
"index_summary_expected_key_size";
+static long defaultExpectedKeySize = 
Long.valueOf(System.getProperty(defaultExpectedKeySizeName, "64"));
+
 // the offset in the keys memory region to look for a given summary 
boundary
 private final SafeMemoryWriter offsets;
 private final SafeMemoryWriter entries;
@@ -85,20 +90,30 @@ public class IndexSummaryBuilder implements AutoCloseable
 }
 }
 
+/**
+ * Build an index summary builder.
+ *
+ * @param expectedKeys - the number of keys we expect in the sstable
+ * @param minIndexInterval - the minimum interval between entries selected 
for sampling
+ * @param samplingLevel - the level at which entries are sampled
+ */
 public IndexSummaryBuilder(long expectedKeys, int minIndexInterval, int 
samplingLevel)
 {
 this.samplingLevel = samplingLevel;
 this.startPoints = Downsampling.getStartPoints(BASE_SAMPLING_LEVEL, 
samplingLevel);
 
+long expectedEntrySize = getEntrySize(defaultExpectedKeySize);
 long maxExpectedEntries = expectedKeys / minIndexInterval;
-if (maxExpectedEntries > Integer.MAX_VALUE)
+long maxExpectedEntriesSize = maxExpectedEntries * expectedEntrySize;
+if (maxExpectedEntriesSize > Integer.MAX_VALUE)
 {
 // that's a _lot_ of keys, and a very low min index interval
-int effectiveMinInterval = (int) Math.ceil((double) 
Integer.MAX_VALUE / expectedKeys);
+int effectiveMinInterval = (int) Math.ceil((double)(expectedKeys * 
expectedEntrySize) / Integer.MAX_VALUE);
 maxExpectedEntries = expectedKeys / effectiveMinInterval;
-assert maxExpectedEntries <= Integer.MAX_VALUE : 
maxExpectedEntries;
-logger.warn("min_index_interval of {} is too low for {} expected 
keys; using interval of {} instead",
-minIndexInterval, expectedKeys, effectiveMinInterval);
+maxExpectedEntriesSize = 

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-09-07 Thread stefania
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/260475d0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/260475d0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/260475d0

Branch: refs/heads/trunk
Commit: 260475d0f2b1f9a8344a3cfb38f6766c9241b52e
Parents: 5dcb354 ae88fd6
Author: Stefania Alborghetti 
Authored: Fri Sep 8 12:43:30 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:43:30 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 123 +++
 3 files changed, 179 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/260475d0/CHANGES.txt
--
diff --cc CHANGES.txt
index 75d9bd6,f4360be..23e6c8b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,14 -1,4 +1,15 @@@
 -3.0.15
 +3.11.1
 + * Add a compaction option to TWCS to ignore sstables overlapping checks 
(CASSANDRA-13418)
 + * BTree.Builder memory leak (CASSANDRA-13754)
 + * Revert CASSANDRA-10368 of supporting non-pk column filtering due to 
correctness (CASSANDRA-13798)
 + * Fix cassandra-stress hang issues when an error during cluster connection 
happens (CASSANDRA-12938)
 + * Better bootstrap failure message when blocked by (potential) range 
movement (CASSANDRA-13744)
 + * "ignore" option is ignored in sstableloader (CASSANDRA-13721)
 + * Deadlock in AbstractCommitLogSegmentManager (CASSANDRA-13652)
 + * Duplicate the buffer before passing it to analyser in SASI operation 
(CASSANDRA-13512)
 + * Properly evict pstmts from prepared statements cache (CASSANDRA-13641)
 +Merged from 3.0:
++ * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
   * Change repair midpoint logging for tiny ranges (CASSANDRA-13603)
   * Better handle corrupt final commitlog segment (CASSANDRA-11995)
   * StreamingHistogram is not thread safe (CASSANDRA-13756)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/260475d0/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
--
diff --cc test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
index f3757a0,ad08ba0..ab0486d
--- a/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
@@@ -45,14 -44,126 +45,137 @@@ import static org.junit.Assert.*
  
  public class IndexSummaryTest
  {
+ private final static Random random = new Random();
 -private final static IPartitioner partitioner = Util.testPartitioner();
++
 +@BeforeClass
 +public static void initDD()
 +{
 +DatabaseDescriptor.daemonInitialization();
++
++final long seed = System.nanoTime();
++System.out.println("Using seed: " + seed);
++random.setSeed(seed);
 +}
 +
 +IPartitioner partitioner = Util.testPartitioner();
  
+ @BeforeClass
+ public static void setup()
+ {
+ final long seed = System.nanoTime();
+ System.out.println("Using seed: " + seed);
+ random.setSeed(seed);
+ }
+ 
+ @Test
+ public void testIndexSummaryKeySizes() throws IOException
+ {
+ testIndexSummaryProperties(32, 100);
+ testIndexSummaryProperties(64, 100);
+ testIndexSummaryProperties(100, 100);
+ testIndexSummaryProperties(1000, 100);
+ testIndexSummaryProperties(1, 100);
+ }
+ 
+ private void testIndexSummaryProperties(int keySize, int numKeys) throws 
IOException
+ {
+ final int minIndexInterval = 1;
+ final List keys = new ArrayList<>(numKeys);
+ 
+ try (IndexSummaryBuilder builder = new IndexSummaryBuilder(numKeys, 
minIndexInterval, BASE_SAMPLING_LEVEL))
+ {
+ for (int i = 0; i < numKeys; i++)
+ {
+ byte[] randomBytes = new byte[keySize];
+ random.nextBytes(randomBytes);
+ DecoratedKey key = 
partitioner.decorateKey(ByteBuffer.wrap(randomBytes));
+ keys.add(key);
+ builder.maybeAddEntry(key, i);
+ }
+ 
+ try(IndexSummary indexSummary = builder.build(partitioner))
+ {
+ assertEquals(numKeys, keys.size());
+ assertEquals(minIndexInterval, 
indexSummary.getMinIndexInterval());
+ assertEquals(numKeys, indexSummary.getMaxNumberOfEntries());
+ assertEquals(numKeys + 1, 
indexSummary.getEstimatedKeyCount());
+ 
+   

[3/6] cassandra git commit: Avoid assertion error when IndexSummary > 2G

2017-09-07 Thread stefania
Avoid assertion error when IndexSummary > 2G

patch by Stefania Alborghetti; reviewed by krummas for CASSANDRA-12014


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae88fd6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae88fd6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae88fd6c

Branch: refs/heads/trunk
Commit: ae88fd6c79b066f12ad76c2c1bfc1620d86bdbc5
Parents: d34f479
Author: Stefania Alborghetti 
Authored: Fri Sep 8 09:33:20 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:37:45 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 121 ++-
 3 files changed, 176 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4302fdf..f4360be 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -95,6 +95,7 @@ Merged from 2.2:
  * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
  * Nodetool upgradesstables/scrub/compact ignores system tables 
(CASSANDRA-13410)
  * Fix NPE issue in StorageService (CASSANDRA-13060)
+ * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
 Merged from 2.2:
  * Avoid starting gossiper in RemoveTest (CASSANDRA-13407)
  * Fix weightedSize() for row-cache reported by JMX and NodeTool 
(CASSANDRA-13393)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java 
b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
index 6110afe..e3006b3 100644
--- a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
+++ b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
@@ -25,7 +25,9 @@ import java.util.TreeMap;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
+import org.apache.cassandra.config.Config;
 import org.apache.cassandra.db.DecoratedKey;
+import org.apache.cassandra.db.TypeSizes;
 import org.apache.cassandra.dht.IPartitioner;
 import org.apache.cassandra.io.util.Memory;
 import org.apache.cassandra.io.util.SafeMemoryWriter;
@@ -36,6 +38,9 @@ public class IndexSummaryBuilder implements AutoCloseable
 {
 private static final Logger logger = 
LoggerFactory.getLogger(IndexSummaryBuilder.class);
 
+static final String defaultExpectedKeySizeName = Config.PROPERTY_PREFIX + 
"index_summary_expected_key_size";
+static long defaultExpectedKeySize = 
Long.valueOf(System.getProperty(defaultExpectedKeySizeName, "64"));
+
 // the offset in the keys memory region to look for a given summary 
boundary
 private final SafeMemoryWriter offsets;
 private final SafeMemoryWriter entries;
@@ -85,20 +90,30 @@ public class IndexSummaryBuilder implements AutoCloseable
 }
 }
 
+/**
+ * Build an index summary builder.
+ *
+ * @param expectedKeys - the number of keys we expect in the sstable
+ * @param minIndexInterval - the minimum interval between entries selected 
for sampling
+ * @param samplingLevel - the level at which entries are sampled
+ */
 public IndexSummaryBuilder(long expectedKeys, int minIndexInterval, int 
samplingLevel)
 {
 this.samplingLevel = samplingLevel;
 this.startPoints = Downsampling.getStartPoints(BASE_SAMPLING_LEVEL, 
samplingLevel);
 
+long expectedEntrySize = getEntrySize(defaultExpectedKeySize);
 long maxExpectedEntries = expectedKeys / minIndexInterval;
-if (maxExpectedEntries > Integer.MAX_VALUE)
+long maxExpectedEntriesSize = maxExpectedEntries * expectedEntrySize;
+if (maxExpectedEntriesSize > Integer.MAX_VALUE)
 {
 // that's a _lot_ of keys, and a very low min index interval
-int effectiveMinInterval = (int) Math.ceil((double) 
Integer.MAX_VALUE / expectedKeys);
+int effectiveMinInterval = (int) Math.ceil((double)(expectedKeys * 
expectedEntrySize) / Integer.MAX_VALUE);
 maxExpectedEntries = expectedKeys / effectiveMinInterval;
-assert maxExpectedEntries <= Integer.MAX_VALUE : 
maxExpectedEntries;
-logger.warn("min_index_interval of {} is too low for {} expected 
keys; using interval of {} instead",
-minIndexInterval, expectedKeys, effectiveMinInterval);
+maxExpectedEntriesSize = maxExpectedEntries * 

[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-09-07 Thread stefania
Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c5bc36a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c5bc36a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c5bc36a

Branch: refs/heads/trunk
Commit: 9c5bc36a773175e3c6f94369ccd64ffbf22381b2
Parents: 83822d1 260475d
Author: Stefania Alborghetti 
Authored: Fri Sep 8 12:44:10 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:44:10 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 123 +++
 3 files changed, 179 insertions(+), 15 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c5bc36a/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c5bc36a/test/unit/org/apache/cassandra/io/sstable/IndexSummaryTest.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[1/6] cassandra git commit: Avoid assertion error when IndexSummary > 2G

2017-09-07 Thread stefania
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 d34f47951 -> ae88fd6c7
  refs/heads/cassandra-3.11 5dcb354cc -> 260475d0f
  refs/heads/trunk 83822d12d -> 9c5bc36a7


Avoid assertion error when IndexSummary > 2G

patch by Stefania Alborghetti; reviewed by krummas for CASSANDRA-12014


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae88fd6c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae88fd6c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae88fd6c

Branch: refs/heads/cassandra-3.0
Commit: ae88fd6c79b066f12ad76c2c1bfc1620d86bdbc5
Parents: d34f479
Author: Stefania Alborghetti 
Authored: Fri Sep 8 09:33:20 2017 +0800
Committer: Stefania Alborghetti 
Committed: Fri Sep 8 12:37:45 2017 +0800

--
 CHANGES.txt |   1 +
 .../io/sstable/IndexSummaryBuilder.java |  70 ---
 .../cassandra/io/sstable/IndexSummaryTest.java  | 121 ++-
 3 files changed, 176 insertions(+), 16 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4302fdf..f4360be 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -95,6 +95,7 @@ Merged from 2.2:
  * Legacy caching options can prevent 3.0 upgrade (CASSANDRA-13384)
  * Nodetool upgradesstables/scrub/compact ignores system tables 
(CASSANDRA-13410)
  * Fix NPE issue in StorageService (CASSANDRA-13060)
+ * Avoid assertion error when IndexSummary > 2G (CASSANDRA-12014)
 Merged from 2.2:
  * Avoid starting gossiper in RemoveTest (CASSANDRA-13407)
  * Fix weightedSize() for row-cache reported by JMX and NodeTool 
(CASSANDRA-13393)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae88fd6c/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java 
b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
index 6110afe..e3006b3 100644
--- a/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
+++ b/src/java/org/apache/cassandra/io/sstable/IndexSummaryBuilder.java
@@ -25,7 +25,9 @@ import java.util.TreeMap;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
+import org.apache.cassandra.config.Config;
 import org.apache.cassandra.db.DecoratedKey;
+import org.apache.cassandra.db.TypeSizes;
 import org.apache.cassandra.dht.IPartitioner;
 import org.apache.cassandra.io.util.Memory;
 import org.apache.cassandra.io.util.SafeMemoryWriter;
@@ -36,6 +38,9 @@ public class IndexSummaryBuilder implements AutoCloseable
 {
 private static final Logger logger = 
LoggerFactory.getLogger(IndexSummaryBuilder.class);
 
+static final String defaultExpectedKeySizeName = Config.PROPERTY_PREFIX + 
"index_summary_expected_key_size";
+static long defaultExpectedKeySize = 
Long.valueOf(System.getProperty(defaultExpectedKeySizeName, "64"));
+
 // the offset in the keys memory region to look for a given summary 
boundary
 private final SafeMemoryWriter offsets;
 private final SafeMemoryWriter entries;
@@ -85,20 +90,30 @@ public class IndexSummaryBuilder implements AutoCloseable
 }
 }
 
+/**
+ * Build an index summary builder.
+ *
+ * @param expectedKeys - the number of keys we expect in the sstable
+ * @param minIndexInterval - the minimum interval between entries selected 
for sampling
+ * @param samplingLevel - the level at which entries are sampled
+ */
 public IndexSummaryBuilder(long expectedKeys, int minIndexInterval, int 
samplingLevel)
 {
 this.samplingLevel = samplingLevel;
 this.startPoints = Downsampling.getStartPoints(BASE_SAMPLING_LEVEL, 
samplingLevel);
 
+long expectedEntrySize = getEntrySize(defaultExpectedKeySize);
 long maxExpectedEntries = expectedKeys / minIndexInterval;
-if (maxExpectedEntries > Integer.MAX_VALUE)
+long maxExpectedEntriesSize = maxExpectedEntries * expectedEntrySize;
+if (maxExpectedEntriesSize > Integer.MAX_VALUE)
 {
 // that's a _lot_ of keys, and a very low min index interval
-int effectiveMinInterval = (int) Math.ceil((double) 
Integer.MAX_VALUE / expectedKeys);
+int effectiveMinInterval = (int) Math.ceil((double)(expectedKeys * 
expectedEntrySize) / Integer.MAX_VALUE);
 maxExpectedEntries = expectedKeys / effectiveMinInterval;
-assert maxExpectedEntries <= Integer.MAX_VALUE : 
maxExpectedEntries;
-logger.warn("min_index_interval of {} is too low for 

[jira] [Commented] (CASSANDRA-13857) Allow MV with only partition key

2017-09-07 Thread Kurt Greaves (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158069#comment-16158069
 ] 

Kurt Greaves commented on CASSANDRA-13857:
--

[~jasonstack] do you mind doing a quick sanity check here? Does the assumption 
that because we support a narrowing of a partition key but with an extra 
clustering key mean that we can support narrowing a views PK to just a 
partition key with no clustering?


> Allow MV with only partition key
> 
>
> Key: CASSANDRA-13857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13857
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>
> We currently disallow creation of a view that has the exact same primary key 
> as the base where no clustering keys are present, however a potential use 
> case would be a view where part of the PK is filtered so as to have a subset 
> of data in the view which is faster for range queries. We actually currently 
> allow this, but only if you have a clustering key defined. If you only have a 
> partitioning key it's not possible.
> From the mailing list, the below example works:
> {code:java}
> CREATE TABLE users (
>   site_id int,
>   user_id text,
>   n int,
>   data set,
>   PRIMARY KEY ((site_id, user_id), n));
> user data is updated and read by PK and sometimes I have to fetch all user 
> for some specific site_id. It appeared that full scan by 
> token(site_id,user_id) filtered by WHERE site_id =  works much 
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
> {code}
> However the following does not:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL 
> PRIMARY KEY ((site_id, user_id));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
> columns are defined for Materialized View other than primary key"
> {code}
> This is because if the clustering key is empty we assume they've only defined 
> the primary key in the partition key and we haven't accounted for this use 
> case. 
> On that note, we also don't allow the following narrowing of the partition 
> key:
> {code}
> CREATE TABLE kurt.base (
> id int,
> uid text,
> data text,
> PRIMARY KEY (id, uid)
> ) 
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
> NULL and uid='1' PRIMARY KEY ((id, uid));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
> columns are defined for Materialized View other than primary key"
> {code}
> But we do allow the following, which works because there is still a 
> clustering key, despite not changing the PK.
> {code}
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
> NULL and uid='1' PRIMARY KEY (id, uid);
> {code}
> And we also allow the following, which is a narrowing of the partition key as 
> above, but with an extra clustering key.
> {code}
> create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
> PRIMARY KEY ((id, uid), clus1, clus2));
> CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
> NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
> KEY ((id, uid, clus1), clus2);
> {code}
> I _think_ supporting these cases is trivial and mostly already handled in the 
> underlying MV write path, so we might be able to get away with just a simple 
> change of [this 
> condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13857) Allow MV with only partition key

2017-09-07 Thread Kurt Greaves (JIRA)

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

Kurt Greaves updated CASSANDRA-13857:
-
Summary: Allow MV with only partition key  (was: Allow MV with same PK but 
a different filtering)

> Allow MV with only partition key
> 
>
> Key: CASSANDRA-13857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13857
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>
> We currently disallow creation of a view that has the exact same primary key 
> as the base where no clustering keys are present, however a potential use 
> case would be a view where part of the PK is filtered so as to have a subset 
> of data in the view which is faster for range queries. We actually currently 
> allow this, but only if you have a clustering key defined. If you only have a 
> partitioning key it's not possible.
> From the mailing list, the below example works:
> {code:java}
> CREATE TABLE users (
>   site_id int,
>   user_id text,
>   n int,
>   data set,
>   PRIMARY KEY ((site_id, user_id), n));
> user data is updated and read by PK and sometimes I have to fetch all user 
> for some specific site_id. It appeared that full scan by 
> token(site_id,user_id) filtered by WHERE site_id =  works much 
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
> {code}
> However the following does not:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL 
> PRIMARY KEY ((site_id, user_id));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
> columns are defined for Materialized View other than primary key"
> {code}
> This is because if the clustering key is empty we assume they've only defined 
> the primary key in the partition key and we haven't accounted for this use 
> case. 
> On that note, we also don't allow the following narrowing of the partition 
> key:
> {code}
> CREATE TABLE kurt.base (
> id int,
> uid text,
> data text,
> PRIMARY KEY (id, uid)
> ) 
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
> NULL and uid='1' PRIMARY KEY ((id, uid));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
> columns are defined for Materialized View other than primary key"
> {code}
> But we do allow the following, which works because there is still a 
> clustering key, despite not changing the PK.
> {code}
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
> NULL and uid='1' PRIMARY KEY (id, uid);
> {code}
> And we also allow the following, which is a narrowing of the partition key as 
> above, but with an extra clustering key.
> {code}
> create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
> PRIMARY KEY ((id, uid), clus1, clus2));
> CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
> NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
> KEY ((id, uid, clus1), clus2);
> {code}
> I _think_ supporting these cases is trivial and mostly already handled in the 
> underlying MV write path, so we might be able to get away with just a simple 
> change of [this 
> condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13857) Allow MV with same PK but a different filtering

2017-09-07 Thread Kurt Greaves (JIRA)

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

Kurt Greaves updated CASSANDRA-13857:
-
Description: 
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries. We actually currently allow 
this, but only if you have a clustering key defined. If you only have a 
partitioning key it's not possible.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
columns are defined for Materialized View other than primary key"
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
columns are defined for Materialized View other than primary key"
{code}
But we do allow the following, which works because there is still a clustering 
key, despite not changing the PK.
{code}
CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY (id, uid);
{code}
And we also allow the following, which is a narrowing of the partition key as 
above, but with an extra clustering key.
{code}
create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
PRIMARY KEY ((id, uid), clus1, clus2));

CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
KEY ((id, uid, clus1), clus2);
{code}

I _think_ supporting these cases is trivial and mostly already handled in the 
underlying MV write path, so we might be able to get away with just a simple 
change of [this 
condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].


  was:
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries. We actually currently allow 
this, but only if you have a clustering key defined. If you only have a 
partitioning key it's not possible.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
columns are defined for Materialized View other than primary key"
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also 

[jira] [Updated] (CASSANDRA-13857) Allow MV with same PK but a different filtering

2017-09-07 Thread Kurt Greaves (JIRA)

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

Kurt Greaves updated CASSANDRA-13857:
-
Description: 
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries. We actually currently allow 
this, but only if you have a clustering key defined. If you only have a 
partitioning key it's not possible.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
InvalidRequest: Error from server: code=2200 [Invalid query] message="No 
columns are defined for Materialized View other than primary key"
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
{code}
But we do allow the following, which works because there is still a clustering 
key, despite not changing the PK.
{code}
CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY (id, uid);
{code}
And we also allow the following, which is a narrowing of the partition key as 
above
{code}
create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
PRIMARY KEY ((id, uid), clus1, clus2));

CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
KEY ((id, uid, clus1), clus2);
{code}

I _think_ supporting these cases is trivial and mostly already handled in the 
underlying MV write path, so we might be able to get away with just a simple 
change of [this 
condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].


  was:
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries. We actually currently allow 
this, but only if you have a clustering key defined. If you only have a 
partitioning key it's not possible.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
{code}
But we do allow the 

[jira] [Updated] (CASSANDRA-13857) Allow MV with same PK but a different filtering

2017-09-07 Thread Kurt Greaves (JIRA)

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

Kurt Greaves updated CASSANDRA-13857:
-
Description: 
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries. We actually currently allow 
this, but only if you have a clustering key defined. If you only have a 
partitioning key it's not possible.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
{code}
But we do allow the following, which works because there is still a clustering 
key, despite not changing the PK.
{code}
CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY (id, uid);
{code}
And we also allow the following, which is a narrowing of the partition key as 
above
{code}
create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
PRIMARY KEY ((id, uid), clus1, clus2));

CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
KEY ((id, uid, clus1), clus2);
{code}

I _think_ supporting these cases is trivial and mostly already handled in the 
underlying MV write path, so we might be able to get away with just a simple 
change of [this 
condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].


  was:
We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
{code}
But we do allow the following, which works because there is still a clustering 
key, despite not changing the PK.
{code}
CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY (id, uid);
{code}
And we also allow the following, which is a narrowing of 

[jira] [Created] (CASSANDRA-13857) Allow MV with same PK but a different filtering

2017-09-07 Thread Kurt Greaves (JIRA)
Kurt Greaves created CASSANDRA-13857:


 Summary: Allow MV with same PK but a different filtering
 Key: CASSANDRA-13857
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13857
 Project: Cassandra
  Issue Type: Bug
Reporter: Kurt Greaves


We currently disallow creation of a view that has the exact same primary key as 
the base where no clustering keys are present, however a potential use case 
would be a view where part of the PK is filtered so as to have a subset of data 
in the view which is faster for range queries.

>From the mailing list, the below example works:
{code:java}
CREATE TABLE users (
  site_id int,
  user_id text,
  n int,
  data set,
  PRIMARY KEY ((site_id, user_id), n));

user data is updated and read by PK and sometimes I have to fetch all user for 
some specific site_id. It appeared that full scan by token(site_id,user_id) 
filtered by WHERE site_id =  works much slower than unfiltered full 
scan on
CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, n, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
PRIMARY KEY ((site_id, user_id), n);
{code}

However the following does not:
{code:java}
CREATE TABLE users (
site_id int,
user_id text,
data set,
PRIMARY KEY ((site_id, user_id)));

CREATE MATERIALIZED VIEW users_1 AS
SELECT site_id, user_id, data
FROM users
WHERE site_id = 1 AND user_id IS NOT NULL 
PRIMARY KEY ((site_id, user_id));
{code}

This is because if the clustering key is empty we assume they've only defined 
the primary key in the partition key and we haven't accounted for this use 
case. 

On that note, we also don't allow the following narrowing of the partition key:
{code}
CREATE TABLE kurt.base (
id int,
uid text,
data text,
PRIMARY KEY (id, uid)
) 

CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY ((id, uid));
{code}
But we do allow the following, which works because there is still a clustering 
key, despite not changing the PK.
{code}
CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT 
NULL and uid='1' PRIMARY KEY (id, uid);
{code}
And we also allow the following, which is a narrowing of the partition key as 
above
{code}
create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text, 
PRIMARY KEY ((id, uid), clus1, clus2));

CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT 
NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL  PRIMARY 
KEY ((id, uid, clus1), clus2);
{code}

I _think_ supporting these cases is trivial and mostly already handled in the 
underlying MV write path, so we might be able to get away with just a simple 
change of [this 
condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-12857) Upgrade procedure between 2.1.x and 3.0.x is broken

2017-09-07 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158042#comment-16158042
 ] 

Jeff Jirsa commented on CASSANDRA-12857:


It doesn't appear that the schema uploaded matches the schema in the 
description. [~ppinstal] , were you ever able to resolve this issue? 


> Upgrade procedure between 2.1.x and 3.0.x is broken
> ---
>
> Key: CASSANDRA-12857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12857
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alexander Yasnogor
>Priority: Critical
> Attachments: cassandra.schema
>
>
> It is not possible safely to do Cassandra in place upgrade from 2.1.14 to 
> 3.0.9.
> Distribution: deb packages from datastax community repo.
> The upgrade was performed according to procedure from this docu: 
> https://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgrdCassandraDetails.html
> Potential reason: The upgrade procedure creates corrupted system_schema and 
> this keyspace get populated in the cluster and kills it.
> We started with one datacenter which contains 19 nodes divided to two racks.
> First rack was successfully upgraded and nodetool describecluster reported 
> two schema versions. One for upgraded nodes, another for non-upgraded nodes.
> On starting new version on a first node from the second rack:
> {code:java}
> INFO  [main] 2016-10-25 13:06:12,103 LegacySchemaMigrator.java:87 - Moving 11 
> keyspaces from legacy schema tables to the new schema keyspace (system_schema)
> INFO  [main] 2016-10-25 13:06:12,104 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@7505e6ac
> INFO  [main] 2016-10-25 13:06:12,200 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@64414574
> INFO  [main] 2016-10-25 13:06:12,204 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@3f2c5f45
> INFO  [main] 2016-10-25 13:06:12,207 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@2bc2d64d
> INFO  [main] 2016-10-25 13:06:12,301 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@77343846
> INFO  [main] 2016-10-25 13:06:12,305 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@19b0b931
> INFO  [main] 2016-10-25 13:06:12,308 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@44bb0b35
> INFO  [main] 2016-10-25 13:06:12,311 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@79f6cd51
> INFO  [main] 2016-10-25 13:06:12,319 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@2fcd363b
> INFO  [main] 2016-10-25 13:06:12,356 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@609eead6
> INFO  [main] 2016-10-25 13:06:12,358 LegacySchemaMigrator.java:148 - 
> Migrating keyspace 
> org.apache.cassandra.schema.LegacySchemaMigrator$Keyspace@7eb7f5d0
> INFO  [main] 2016-10-25 13:06:13,958 LegacySchemaMigrator.java:97 - 
> Truncating legacy schema tables
> INFO  [main] 2016-10-25 13:06:26,474 LegacySchemaMigrator.java:103 - 
> Completed migration of legacy schema tables
> INFO  [main] 2016-10-25 13:06:26,474 StorageService.java:521 - Populating 
> token metadata from system tables
> INFO  [main] 2016-10-25 13:06:26,796 StorageService.java:528 - Token 
> metadata: Normal Tokens: [HUGE LIST of tokens]
> INFO  [main] 2016-10-25 13:06:29,066 ColumnFamilyStore.java:389 - 
> Initializing ...
> INFO  [main] 2016-10-25 13:06:29,066 ColumnFamilyStore.java:389 - 
> Initializing ...
> INFO  [main] 2016-10-25 13:06:45,894 AutoSavingCache.java:165 - Completed 
> loading (2 ms; 460 keys) KeyCache cache
> INFO  [main] 2016-10-25 13:06:46,982 StorageService.java:521 - Populating 
> token metadata from system tables
> INFO  [main] 2016-10-25 13:06:47,394 StorageService.java:528 - Token 
> metadata: Normal Tokens:[HUGE LIST of tokens]
> INFO  [main] 2016-10-25 13:06:47,420 LegacyHintsMigrator.java:88 - Migrating 
> legacy hints to new storage
> INFO  [main] 2016-10-25 13:06:47,420 LegacyHintsMigrator.java:91 - Forcing a 
> major compaction of system.hints table
> INFO  [main] 2016-10-25 13:06:50,587 LegacyHintsMigrator.java:95 - Writing 
> legacy hints to the new storage
> INFO  [main] 2016-10-25 13:06:53,927 LegacyHintsMigrator.java:99 - Truncating 
> system.hints table
> 
> INFO  [main] 2016-10-25 13:06:56,572 

[jira] [Commented] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8

2017-09-07 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158040#comment-16158040
 ] 

Jeff Jirsa commented on CASSANDRA-13513:


[~anujaja...@gmail.com] are you still seeing this? Were you able to resolve it? 
Are you able to provide the schema for that table?


> Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 
> 3.0.8
> --
>
> Key: CASSANDRA-13513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13513
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: DSE 5.0.8, cqlsh 5.0.1 , Cassandra 3.0.12.1656 , Ubuntu 
> 14.04
>Reporter: Anuja Mandlecha
>
> Hi,
> While querying Cassandra table using DBeaver or using DataStax Node.js Driver 
> getting below error. 
> {code}
> WARN  [SharedPool-Worker-2] 2017-05-09 12:55:18,654  
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137) 
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320) 
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_101]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> {code}
> Query used is 
> {code}
> select * from dynocloud.user_info where company_name='DS' allow filtering;
> {code} 
> This query returns data when run in cql shell. 
> Also if we give limit 100 to the same query or change the value to 
> company_name, the query returns results. The index definition is 
> {code} 
> CREATE INDEX company_name_userindex ON dynocloud.user_info (company_name);
> {code} 
> Thanks,
> Anuja Mandlecha



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-12014) IndexSummary > 2G causes an assertion error

2017-09-07 Thread Stefania (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157995#comment-16157995
 ] 

Stefania commented on CASSANDRA-12014:
--

Thanks for the review and the rebase. I've updated my 3.0 
[branch|https://github.com/stef1927/cassandra/commits/12014-simplified-3.0] 
with the rebased code. The CI results don't look too good, there are several 
dtest failures and the unit tests did not run. I've launched CI on our servers 
for 3.0. I'll merge to 3.0, 3.11 and trunk once I have the results. I don't 
expect any problems but just in case.



> IndexSummary > 2G causes an assertion error
> ---
>
> Key: CASSANDRA-12014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12014
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> {noformat}
> ERROR [CompactionExecutor:1546280] 2016-06-01 13:21:00,444  
> CassandraDaemon.java:229 - Exception in thread 
> Thread[CompactionExecutor:1546280,1,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.maybeAddEntry(IndexSummaryBuilder.java:171)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.append(SSTableWriter.java:634)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.afterAppend(SSTableWriter.java:179)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:205) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {noformat}
> I believe this can be fixed by raising the min_index_interval, but we should 
> have a better method of coping with this than throwing the AE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13856) Optimize ByteBuf reallocations in the native protocol pipeline

2017-09-07 Thread Jason Brown (JIRA)
Jason Brown created CASSANDRA-13856:
---

 Summary: Optimize ByteBuf reallocations in the native protocol 
pipeline
 Key: CASSANDRA-13856
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13856
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jason Brown
Assignee: Jason Brown
Priority: Minor


This is a follow up to CASSANDRA-13789. I discovered we reallocate the 
{{ByteBuf}} when writing data to it, and it would be nice to size the buffer 
correctly up-front to avoid reallocating it. I'm not sure how easy that is, nor 
if the cost of the realloc is cheaper than calculating the size needed for the 
buffer. Adding this ticket, nonetheless, to explore that optimization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13789) Reduce memory copies and object creations when acting on ByteBufs

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157881#comment-16157881
 ] 

Jason Brown commented on CASSANDRA-13789:
-

rebased on CASSANDRA-13852, and [rerunning 
dtests|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/294/]
 to get a better run

> Reduce memory copies and object creations when acting on  ByteBufs
> --
>
> Key: CASSANDRA-13789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13789
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Norman Maurer
>Assignee: Norman Maurer
> Fix For: 4.0
>
> Attachments: 
> 0001-CBUtil.sizeOfLongString-encodes-String-to-byte-to-ca.patch, 
> 0001-Reduce-memory-copies-and-object-creations-when-actin.patch
>
>
> There are multiple "low-hanging-fruits" when it comes to reduce memory copies 
> and object allocations when acting on ByteBufs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13852:

Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

committed as sha {{83822d12d87dcb3aaad2b1e670e57ebef4ab1c36}}.

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-13855) URL Seed provider

2017-09-07 Thread Jon Haddad (JIRA)

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

Jon Haddad reassigned CASSANDRA-13855:
--

Assignee: Jon Haddad

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Minor
>  Labels: lhf
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



cassandra git commit: Race condition when closing stream sessions

2017-09-07 Thread jasobrown
Repository: cassandra
Updated Branches:
  refs/heads/trunk bab76eba9 -> 83822d12d


Race condition when closing stream sessions

patch by jasobrown; reviewed by Blake Eggleston for CASSANDRA-13852


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83822d12
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83822d12
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83822d12

Branch: refs/heads/trunk
Commit: 83822d12d87dcb3aaad2b1e670e57ebef4ab1c36
Parents: bab76eb
Author: Jason Brown 
Authored: Wed Sep 6 17:37:24 2017 -0700
Committer: Jason Brown 
Committed: Thu Sep 7 16:45:23 2017 -0700

--
 CHANGES.txt |  1 +
 .../async/RebufferingByteBufDataInputPlus.java  |  8 +++---
 .../RebufferingByteBufDataInputPlusTest.java| 28 
 3 files changed, 34 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/83822d12/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0175992..077fd7f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Race condition when closing stream sessions (CASSANDRA-13852)
  * NettyFactoryTest is failing in trunk on macOS (CASSANDRA-13831)
  * Allow changing log levels via nodetool for related classes (CASSANDRA-12696)
  * Add stress profile yaml with LWT (CASSANDRA-7960)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/83822d12/src/java/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlus.java
--
diff --git 
a/src/java/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlus.java 
b/src/java/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlus.java
index 580bc03..1f32aa8 100644
--- 
a/src/java/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlus.java
+++ 
b/src/java/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlus.java
@@ -165,14 +165,16 @@ public class RebufferingByteBufDataInputPlus extends 
RebufferingInputStream impl
  * {@inheritDoc}
  *
  * As long as this method is invoked on the consuming thread the returned 
value will be accurate.
+ *
+ * @throws EOFException thrown when no bytes are buffered and {@link 
#closed} is true.
  */
 @Override
 public int available() throws EOFException
 {
-if (closed)
-throw new EOFException();
+   final int availableBytes = queuedByteCount.get() + (buffer != null ? 
buffer.remaining() : 0);
 
-   final  int availableBytes = queuedByteCount.get() + (buffer != null ? 
buffer.remaining() : 0);
+if (availableBytes == 0 && closed)
+throw new EOFException();
 
 if (!channelConfig.isAutoRead() && availableBytes < lowWaterMark)
 channelConfig.setAutoRead(true);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/83822d12/test/unit/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlusTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlusTest.java
 
b/test/unit/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlusTest.java
index 4968196..2961d9a 100644
--- 
a/test/unit/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlusTest.java
+++ 
b/test/unit/org/apache/cassandra/net/async/RebufferingByteBufDataInputPlusTest.java
@@ -123,4 +123,32 @@ public class RebufferingByteBufDataInputPlusTest
 ByteBuffer buf = ByteBuffer.allocate(1);
 inputPlus.read(buf);
 }
+
+@Test (expected = EOFException.class)
+public void available_closed() throws EOFException
+{
+inputPlus.markClose();
+inputPlus.available();
+}
+
+@Test
+public void available_HappyPath() throws EOFException
+{
+int size = 4;
+buf = channel.alloc().heapBuffer(size);
+buf.writerIndex(size);
+inputPlus.append(buf);
+Assert.assertEquals(size, inputPlus.available());
+}
+
+@Test
+public void available_ClosedButWithBytes() throws EOFException
+{
+int size = 4;
+buf = channel.alloc().heapBuffer(size);
+buf.writerIndex(size);
+inputPlus.append(buf);
+inputPlus.markClose();
+Assert.assertEquals(size, inputPlus.available());
+}
 }


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13855) URL Seed provider

2017-09-07 Thread Jon Haddad (JIRA)
Jon Haddad created CASSANDRA-13855:
--

 Summary: URL Seed provider
 Key: CASSANDRA-13855
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jon Haddad
Priority: Minor


Seems like including a dead simple seed provider that can fetch from a URL, 1 
line per seed, would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13855) URL Seed provider

2017-09-07 Thread Jon Haddad (JIRA)

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

Jon Haddad updated CASSANDRA-13855:
---
Labels: lhf  (was: )

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Priority: Minor
>  Labels: lhf
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Blake Eggleston (JIRA)

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

Blake Eggleston updated CASSANDRA-13852:

Status: Ready to Commit  (was: Patch Available)

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157862#comment-16157862
 ] 

Blake Eggleston commented on CASSANDRA-13852:
-

+1

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13781) Cassandra 3.10 jvm.options default -XX:+UseNUMA may core OpenJDK on some aarch64 machines at os::Linux::libnuma_init()

2017-09-07 Thread Yangzheng Bai (JIRA)

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

Yangzheng Bai updated CASSANDRA-13781:
--
Component/s: Configuration

> Cassandra 3.10 jvm.options default -XX:+UseNUMA may core OpenJDK on some 
> aarch64 machines at os::Linux::libnuma_init()
> --
>
> Key: CASSANDRA-13781
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13781
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Yangzheng Bai
>
> We tried Oracle JDK, Linaro JDK, Zulu JDK and default OpenJDK, all of them 
> cored at the same place: os::Linux::libnuma_init() -> 
> os::Linux::rebuild_cpu_to_node_map()
> Removed -XX:+UseNUMA option solved the problem. Therefore we should remove 
> -XX:+UseNUMA as an default option on aarch64 machines because x86_64 and 
> aarch64 may have different implementations on how NUMA is reported. And 
> -XX:+UseNUMA is currently not supporting G1GC anyway 
> (https://bugs.openjdk.java.net/browse/JDK-8046147), adding it as default 
> option may not have performance gain for future Java default G1GC.
> {noformat}
> root@1pqd-1:/usr/share/cassandra/lib# /usr/sbin/cassandra -R -f
> *** Error in `java': free(): invalid pointer: 0x800058c0 ***
> Aborted (core dumped)
> (gdb) bt
> #0  0x8719d528 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x8719e9e0 in __GI_abort () at abort.c:89
> #2  0x871d48c4 in __libc_message (do_abort=do_abort@entry=2,
> fmt=fmt@entry=0x87285550 "*** Error in `%s': %s: 0x%s ***\n") at 
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x871da2ec in malloc_printerr (action=, 
> str=0x87285720 "free(): invalid pointer",
> ptr=, ar_ptr=) at malloc.c:5006
> #4  0x871db088 in _int_free (av=0x872ad9a0 , 
> p=, have_lock=0) at malloc.c:3867
> #5  0x86dbccc4 in os::Linux::rebuild_cpu_to_node_map() ()
>from /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #6  0x86dbd048 in os::Linux::libnuma_init() () from 
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #7  0x86dc34ac in os::init_2() () from 
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #8  0x86f0f374 in Threads::create_vm(JavaVMInitArgs*, bool*) ()
>from /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #9  0x86bb7b80 in JNI_CreateJavaVM () from 
> /usr/lib/jvm/java-8-linaro/jre/lib/aarch64/server/libjvm.so
> #10 0x872ba75c in InitializeJVM (ifn=, 
> penv=0x86533a38, pvm=0x86533a30)
> at 
> /home/buildslave/workspace/jdk8-build-release/BUILD_TYPE/release/JVM_VARIANT/server/label/aarch64-06/jdk8u-server-release-1704/jdk/src/share/bin/java.c:1215
> #11 JavaMain (_args=)
> at 
> /home/buildslave/workspace/jdk8-build-release/BUILD_TYPE/release/JVM_VARIANT/server/label/aarch64-06/jdk8u-server-release-1704/jdk/src/share/bin/java.c:376
> #12 0x87133fc4 in start_thread (arg=0x872ba6d0 ) at 
> pthread_create.c:335
> #13 0x87232290 in thread_start () at 
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:89
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157855#comment-16157855
 ] 

Jason Brown commented on CASSANDRA-13852:
-

This fix should also resolve the hanging in system_auth_ks_is_alterable_test 
(auth_test.TestAuth)

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13854) Cassandra should provide a parameter to completely disable metrics-core

2017-09-07 Thread Yangzheng Bai (JIRA)
Yangzheng Bai created CASSANDRA-13854:
-

 Summary: Cassandra should provide a parameter to completely 
disable metrics-core
 Key: CASSANDRA-13854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13854
 Project: Cassandra
  Issue Type: Improvement
  Components: Metrics
Reporter: Yangzheng Bai
Priority: Minor


We found that Java metrics-core contributes 10%~15% performance impact on some 
aarch64 systems. Because metrics update is heavily rely on atomic instructions 
and the cost of atomic instruction is one of the bottlenecks which prevents 
Cassandra scaling up to 64 or more cores.

Because Java metrics-core is only for diagnostic purpose, we suggest there 
should be a parameter in cassandra.yaml to completely disable it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13853) nodetool describecluster should be more informative

2017-09-07 Thread Jon Haddad (JIRA)
Jon Haddad created CASSANDRA-13853:
--

 Summary: nodetool describecluster should be more informative
 Key: CASSANDRA-13853
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13853
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jon Haddad


Additional information we should be displaying:

* Total node count
* List of datacenters, RF, with number of nodes per dc, how many are down, 
* Version(s)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13837) Hanging threads in BulkLoader

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13837:

Status: Patch Available  (was: Open)

> Hanging threads in BulkLoader
> -
>
> Key: CASSANDRA-13837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13837
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>
> [~krummas] discovered some threads that were not closing correctly when he 
> fixed CASSANDRA-13836. We suspect this is due to 
> CASSANDRA-8457/CASSANDRA-12229.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13852:

Status: Patch Available  (was: Open)

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13837) Hanging threads in BulkLoader

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157655#comment-16157655
 ] 

Jason Brown commented on CASSANDRA-13837:
-

[~krummas] do you mind reviewing?

> Hanging threads in BulkLoader
> -
>
> Key: CASSANDRA-13837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13837
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>
> [~krummas] discovered some threads that were not closing correctly when he 
> fixed CASSANDRA-13836. We suspect this is due to 
> CASSANDRA-8457/CASSANDRA-12229.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13837) Hanging threads in BulkLoader

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157641#comment-16157641
 ] 

Jason Brown commented on CASSANDRA-13837:
-

Patch here:

||13837||
|[branch|https://github.com/jasobrown/cassandra/tree/13837]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/293/]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13837]|

Basically, we just need to make the netty {{EventLoopGroup}} threads daemon 
threads

> Hanging threads in BulkLoader
> -
>
> Key: CASSANDRA-13837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13837
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>
> [~krummas] discovered some threads that were not closing correctly when he 
> fixed CASSANDRA-13836. We suspect this is due to 
> CASSANDRA-8457/CASSANDRA-12229.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13789) Reduce memory copies and object creations when acting on ByteBufs

2017-09-07 Thread Michael Kjellman (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157588#comment-16157588
 ] 

Michael Kjellman commented on CASSANDRA-13789:
--

Actual fix looks good so +1.. Awesome to have added some tests too.

> Reduce memory copies and object creations when acting on  ByteBufs
> --
>
> Key: CASSANDRA-13789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13789
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Norman Maurer
>Assignee: Norman Maurer
> Fix For: 4.0
>
> Attachments: 
> 0001-CBUtil.sizeOfLongString-encodes-String-to-byte-to-ca.patch, 
> 0001-Reduce-memory-copies-and-object-creations-when-actin.patch
>
>
> There are multiple "low-hanging-fruits" when it comes to reduce memory copies 
> and object allocations when acting on ByteBufs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13789) Reduce memory copies and object creations when acting on ByteBufs

2017-09-07 Thread Norman Maurer (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157554#comment-16157554
 ] 

Norman Maurer commented on CASSANDRA-13789:
---

[~jasobrown] Doh! I guess I need to buy the beer now 

> Reduce memory copies and object creations when acting on  ByteBufs
> --
>
> Key: CASSANDRA-13789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13789
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Norman Maurer
>Assignee: Norman Maurer
> Fix For: 4.0
>
> Attachments: 
> 0001-CBUtil.sizeOfLongString-encodes-String-to-byte-to-ca.patch, 
> 0001-Reduce-memory-copies-and-object-creations-when-actin.patch
>
>
> There are multiple "low-hanging-fruits" when it comes to reduce memory copies 
> and object allocations when acting on ByteBufs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13789) Reduce memory copies and object creations when acting on ByteBufs

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157547#comment-16157547
 ] 

Jason Brown commented on CASSANDRA-13789:
-

Pushed a fix here:

||13789-fixes||
|[branch|https://github.com/jasobrown/cassandra/tree/13789-fixes]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/291/]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/13789-fixes]|

The problem was in [~norman]'s patch, in both {{CBUtil#writeString}} and 
{{CBUtil#writeLongString}} he was bumping the writerIndex via 
{{ByteBuf#writerIndex(int)}}. The problem is that if the new writerIndex value 
exceeds the capacity of the buffer it throws an {{IndexOutOfBoundsException}}. 
Previously, we were calling {{ByteBuf#writeShort}} or {{ByteBuf#writeLong}}, 
which reallocates the buffer if the new writerIndex is larger than the current 
size.

For now, I've reverted to calling {{ByteBuf#writeShort}} (or 
{{ByteBuf#writeLong}}), to restore previous behavior (that passes!), and I've 
added a new {{CBUtilTest}}, as well.

As a further optimization, we can find out why the {{ByteBuf}} is being 
reallocated to begin with, but that's for another jira.


> Reduce memory copies and object creations when acting on  ByteBufs
> --
>
> Key: CASSANDRA-13789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13789
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Norman Maurer
>Assignee: Norman Maurer
> Fix For: 4.0
>
> Attachments: 
> 0001-CBUtil.sizeOfLongString-encodes-String-to-byte-to-ca.patch, 
> 0001-Reduce-memory-copies-and-object-creations-when-actin.patch
>
>
> There are multiple "low-hanging-fruits" when it comes to reduce memory copies 
> and object allocations when acting on ByteBufs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13852) Race condition when closing stream sessions (4.0)

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13852:

Summary: Race condition when closing stream sessions (4.0)  (was: Race 
condition when closing stream sessions)

> Race condition when closing stream sessions (4.0)
> -
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-13852) Race condition when closing stream sessions

2017-09-07 Thread Blake Eggleston (JIRA)

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

Blake Eggleston reassigned CASSANDRA-13852:
---

Assignee: Jason Brown
Reviewer: Blake Eggleston

> Race condition when closing stream sessions
> ---
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13852) Race condition when closing stream sessions

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157383#comment-16157383
 ] 

Jason Brown commented on CASSANDRA-13852:
-

Patch to fix this problem here:

||hang||
|[branch|https://github.com/jasobrown/cassandra/tree/bootstrap-dtest-hang]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/287]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/bootstrap-dtest-hang]|

There are other dtests problems happening, and I"m on those now, as well.

> Race condition when closing stream sessions
> ---
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13852) Race condition when closing stream sessions

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13852:

Description: bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging 
due to a race condition that can occur when waiting for a streaming COMPLETE 
message and the remote side has already closed the connection. We do not check 
to see if we still have remaining bytes buffered for consumption in 
{{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
{{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
on subsequent calls.  (was: bootstrap_test:TestBootstrap.manual_bootstrap_test 
is hanging due to a race condition that can occur when waiting for a streaming 
COMPLETE message and the remote side has already closed the connection. We do 
not check to see if we still have remaining bytes buffered for consumption in 
{{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
{{EOFException}]. We should consume the bytes, then throw an {{EOFException}} 
on subsequent calls.)

> Race condition when closing stream sessions
> ---
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13852) Race condition when closing stream sessions

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157379#comment-16157379
 ] 

Jason Brown commented on CASSANDRA-13852:
-

This was discovered via bootstrap_test:TestBootstrap.manual_bootstrap_test 
hanging when running dtests

> Race condition when closing stream sessions
> ---
>
> Key: CASSANDRA-13852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>
> bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
> condition that can occur when waiting for a streaming COMPLETE message and 
> the remote side has already closed the connection. We do not check to see if 
> we still have remaining bytes buffered for consumption in 
> {{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
> {{EOFException}}. We should consume the bytes, then throw an {{EOFException}} 
> on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13852) Race condition when closing stream sessions

2017-09-07 Thread Jason Brown (JIRA)
Jason Brown created CASSANDRA-13852:
---

 Summary: Race condition when closing stream sessions
 Key: CASSANDRA-13852
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13852
 Project: Cassandra
  Issue Type: Bug
Reporter: Jason Brown


bootstrap_test:TestBootstrap.manual_bootstrap_test is hanging due to a race 
condition that can occur when waiting for a streaming COMPLETE message and the 
remote side has already closed the connection. We do not check to see if we 
still have remaining bytes buffered for consumption in 
{{RebufferringByteBufDataInputPlus}}, but always go ahead and throw an 
{{EOFException}]. We should consume the bytes, then throw an {{EOFException}} 
on subsequent calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13831:

   Resolution: Fixed
Fix Version/s: (was: 4.x)
   4.0
   Status: Resolved  (was: Ready to Commit)

committed as sha {{bab76eba958241bbfca33e9fc6fe663ce230b034}} to trunk. And 
I've cleaned up the CHANGES entrie3s as per [~iamaleksey]'s request.

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.0
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



cassandra git commit: NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread jasobrown
Repository: cassandra
Updated Branches:
  refs/heads/trunk e8b559ce2 -> bab76eba9


NettyFactoryTest is failing in trunk on MacOS

patch by jasobrown; reviewed by Aleksey Yeschenko for CASSANDRA-13831


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bab76eba
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bab76eba
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bab76eba

Branch: refs/heads/trunk
Commit: bab76eba958241bbfca33e9fc6fe663ce230b034
Parents: e8b559c
Author: Jason Brown 
Authored: Thu Aug 31 05:27:16 2017 -0700
Committer: Jason Brown 
Committed: Thu Sep 7 11:02:13 2017 -0700

--
 CHANGES.txt   |  7 ---
 src/java/org/apache/cassandra/net/async/NettyFactory.java |  7 +--
 .../apache/cassandra/service/NativeTransportService.java  |  5 +
 .../org/apache/cassandra/net/async/NettyFactoryTest.java  | 10 ++
 4 files changed, 20 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bab76eba/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0a38e6f..0175992 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,11 +1,12 @@
 4.0
+ * NettyFactoryTest is failing in trunk on macOS (CASSANDRA-13831)
  * Allow changing log levels via nodetool for related classes (CASSANDRA-12696)
  * Add stress profile yaml with LWT (CASSANDRA-7960)
  * Reduce memory copies and object creations when acting on ByteBufs 
(CASSANDRA-13789)
- * simplify mx4j configuration (Cassandra-13578)
+ * Simplify mx4j configuration (Cassandra-13578)
  * Fix trigger example on 4.0 (CASSANDRA-13796)
- * force minumum timeout value (CASSANDRA-9375)
- * use netty for streaming (CASSANDRA-12229)
+ * Force minumum timeout value (CASSANDRA-9375)
+ * Use netty for streaming (CASSANDRA-12229)
  * Use netty for internode messaging (CASSANDRA-8457)
  * Add bytes repaired/unrepaired to nodetool tablestats (CASSANDRA-13774)
  * Don't delete incremental repair sessions if they still have sstables 
(CASSANDRA-13758)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bab76eba/src/java/org/apache/cassandra/net/async/NettyFactory.java
--
diff --git a/src/java/org/apache/cassandra/net/async/NettyFactory.java 
b/src/java/org/apache/cassandra/net/async/NettyFactory.java
index 762c39b..cb4bd22 100644
--- a/src/java/org/apache/cassandra/net/async/NettyFactory.java
+++ b/src/java/org/apache/cassandra/net/async/NettyFactory.java
@@ -19,7 +19,6 @@ import io.netty.channel.ChannelOption;
 import io.netty.channel.ChannelPipeline;
 import io.netty.channel.EventLoopGroup;
 import io.netty.channel.ServerChannel;
-import io.netty.channel.epoll.Epoll;
 import io.netty.channel.epoll.EpollEventLoopGroup;
 import io.netty.channel.epoll.EpollServerSocketChannel;
 import io.netty.channel.epoll.EpollSocketChannel;
@@ -54,6 +53,7 @@ import org.apache.cassandra.service.NativeTransportService;
 import org.apache.cassandra.utils.ChecksumType;
 import org.apache.cassandra.utils.CoalescingStrategies;
 import org.apache.cassandra.utils.FBUtilities;
+import org.apache.cassandra.utils.NativeLibrary;
 
 /**
  * A factory for building Netty {@link Channel}s. Channels here are setup with 
a pipeline to participate
@@ -92,11 +92,6 @@ public final class NettyFactory
 }
 
 private static final boolean DEFAULT_USE_EPOLL = 
NativeTransportService.useEpoll();
-static
-{
-if (!DEFAULT_USE_EPOLL)
-logger.warn("epoll not availble {}", Epoll.unavailabilityCause());
-}
 
 /**
  * The size of the receive queue for the outbound channels. As outbound 
channels do not receive data

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bab76eba/src/java/org/apache/cassandra/service/NativeTransportService.java
--
diff --git a/src/java/org/apache/cassandra/service/NativeTransportService.java 
b/src/java/org/apache/cassandra/service/NativeTransportService.java
index 28e7dac..b184442 100644
--- a/src/java/org/apache/cassandra/service/NativeTransportService.java
+++ b/src/java/org/apache/cassandra/service/NativeTransportService.java
@@ -37,6 +37,7 @@ import org.apache.cassandra.metrics.AuthMetrics;
 import org.apache.cassandra.metrics.ClientMetrics;
 import org.apache.cassandra.transport.RequestThreadPoolExecutor;
 import org.apache.cassandra.transport.Server;
+import org.apache.cassandra.utils.NativeLibrary;
 
 /**
  * Handles native transport server lifecycle and associated resources. Lazily 
initialized.
@@ -159,6 +160,10 @@ public class NativeTransportService
 public static 

[jira] [Updated] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13831:
--
Status: Ready to Commit  (was: Patch Available)

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157270#comment-16157270
 ] 

Aleksey Yeschenko commented on CASSANDRA-13831:
---

+1. On commit, can you please fix your recent CHANGES.txt entries in the log to 
start with upper case, like every other line in the list?

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157250#comment-16157250
 ] 

Aleksey Yeschenko edited comment on CASSANDRA-13842 at 9/7/17 5:10 PM:
---

Committed as 
[5893020fd9f2ca783be13a5a0974504632529440|https://github.com/apache/cassandra-dtest/commit/5893020fd9f2ca783be13a5a0974504632529440],
 thanks.


was (Author: iamaleksey):
Committed, thanks.

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13842:
--
Priority: Minor  (was: Major)

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>Priority: Minor
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13842:
--
Component/s: Testing

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13842:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed, thanks.

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



cassandra-dtest git commit: Fix batchlog replay compatibility tests

2017-09-07 Thread aleksey
Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 926903858 -> 5893020fd


Fix batchlog replay compatibility tests

patch by Aleksey Yeschenko; reviewed by Jeff Jirsa for CASSANDRA-13842


Project: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/commit/5893020f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/tree/5893020f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/diff/5893020f

Branch: refs/heads/master
Commit: 5893020fd9f2ca783be13a5a0974504632529440
Parents: 9269038
Author: Aleksey Yeschenko 
Authored: Thu Sep 7 17:31:35 2017 +0100
Committer: Aleksey Yeschenko 
Committed: Thu Sep 7 17:48:10 2017 +0100

--
 batch_test.py | 7 +++
 1 file changed, 7 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/5893020f/batch_test.py
--
diff --git a/batch_test.py b/batch_test.py
index 5c25c46..f8b9881 100644
--- a/batch_test.py
+++ b/batch_test.py
@@ -383,6 +383,13 @@ class TestBatch(Tester):
 """
 session.execute(query)
 
+# batchlog replay skips over all entries that are younger than
+# 2 * write_request_timeout_in_ms ms: 1x timeout for all mutations to 
be written,
+# and another 1x timeout for batch remove mutation to be received.
+delay = 2 * coordinator.get_conf_option('write_request_timeout_in_ms') 
/ 1000.0 + 1
+debug('Sleeping for {}s for the batches to not be 
skipped'.format(delay))
+time.sleep(delay)
+
 total_batches_replayed = 0
 blm = make_mbean('db', type='BatchlogManager')
 


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157246#comment-16157246
 ] 

Jeff Jirsa commented on CASSANDRA-13842:


+1


> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157243#comment-16157243
 ] 

Aleksey Yeschenko commented on CASSANDRA-13842:
---

A simple patch 
[here|https://github.com/iamaleksey/cassandra-dtest/commits/13842].

The problem with the tests is that they don’t take into account the full 
behaviour of batchlog replay. In particular,
batchlog will *not* replay a batch if it’s younger than 2 times write rpc 
timeout. The reasoning for this is that
there is a good chance that the batch can still succeed up until that point and 
be removed by the remote coordinator -
thus avoiding redundant replay. 2 * timeout is there for batched mutations 
timeout + remove from batchlog mutation
timeout.

One way to fix this would be to introduce a special argument to batchlog replay 
methods that would ignore the check and
replay everything it has, ignoring that optimisation. But on 3.0 it has 
correctness implications, since we store last replayed
batch id as the lower bound for the next replay cycle. In 2.2 it’s a bit safer, 
but we need it to be addressed in both versions -
and I’m not comfortable with making such changes in minor releases.

The other way to fix it is by introducing a deterministic delay to age the 
batches by 2 * timeout. It adds 20 extra seconds per test,
for a total of 40 seconds, but I don’t see a better way unfortunately. 
Shouldn’t be flaky however.

P.S. The reason it passes on MacOS and fails on Linux is that the test runs 
very, very slowly on MacOS. 160+ seconds vs. 30 seconds on Linux.
It naturally has just enough time for the batch to age, so when we force its 
replay, it is replayed reliably.

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13842:
--
Labels: dtest  (was: )
Status: Patch Available  (was: In Progress)

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>  Labels: dtest
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13842) dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test

2017-09-07 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-13842:
--
Reviewer: Jeff Jirsa

> dtest failure: batch_test.TestBatch.batchlog_replay_compatibility_?_test
> 
>
> Key: CASSANDRA-13842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13842
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>
> batch_test.TestBatch.batchlog_replay_compatibility_1_test and 
> batch_test.TestBatch.batchlog_replay_compatibility_4_test are failing:
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_1_test/
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/160/testReport/batch_test/TestBatch/batchlog_replay_compatibility_4_test/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13848) Allow sstabledump to do a json object per partition to better handle large sstables

2017-09-07 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157187#comment-16157187
 ] 

Brandon Williams commented on CASSANDRA-13848:
--

We do have the -k option for keys, if you know them a priori, but I guess in 
the case that you don't or want to do the entire table this could be useful.  
Although, in combination with sstablekeys, you could probably automate this in 
the current state of the art.

> Allow sstabledump to do a json object per partition to better handle large 
> sstables
> ---
>
> Key: CASSANDRA-13848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13848
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jeff Jirsa
>Priority: Trivial
>  Labels: lhf
>
> sstable2json / sstabledump make a huge json document of the whole file. For 
> very large sstables this makes it impossible to load in memory to do anything 
> with it. Allowing users to Break it into small json objects per partition 
> would be useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation

2017-09-07 Thread ZhaoYang (JIRA)

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

ZhaoYang updated CASSANDRA-13622:
-
Status: Ready to Commit  (was: Patch Available)

> Better config validation/documentation
> --
>
> Key: CASSANDRA-13622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13622
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Kurt Greaves
>Assignee: ZhaoYang
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
>
> There are a number of properties in the yaml that are "in_mb", however 
> resolve to bytes when calculated in {{DatabaseDescriptor.java}}, but are 
> stored in int's. This means that their maximum values are 2047, as any higher 
> when converted to bytes overflows the int.
> Where possible/reasonable we should convert these to be long's, and stored as 
> long's. If there is no reason for the value to ever be >2047 we should at 
> least document that as the max value, or better yet make it error if set 
> higher than that. Noting that although it's bad practice to increase a lot of 
> them to such high values, there may be cases where it is necessary and in 
> which case we should handle it appropriately rather than overflowing and 
> surprising the user. That is, causing it to break but not in the way the user 
> expected it to :)
> Following are functions that currently could be at risk of the above:
> {code:java|title=DatabaseDescriptor.java}
> getThriftFramedTransportSize()
> getMaxValueSize()
> getCompactionLargePartitionWarningThreshold()
> getCommitLogSegmentSize()
> getNativeTransportMaxFrameSize()
> # These are in KB so max value of 2096128
> getBatchSizeWarnThreshold()
> getColumnIndexSize()
> getColumnIndexCacheSize()
> getMaxMutationSize()
> {code}
> Note we may not actually need to fix all of these, and there may be more. 
> This was just from a rough scan over the code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Jason Brown (JIRA)

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

Jason Brown updated CASSANDRA-13831:

Status: Patch Available  (was: Open)

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156981#comment-16156981
 ] 

Jason Brown commented on CASSANDRA-13831:
-

ahh, sorry, already pushed that change about 10 minutes after the last UPDATE 
tag. Marking Patch Available now.

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-13175) Integrate "Error Prone" Code Analyzer

2017-09-07 Thread Stefan Podkowinski (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156931#comment-16156931
 ] 

Stefan Podkowinski edited comment on CASSANDRA-13175 at 9/7/17 1:18 PM:


The javac error that causes ant to fail is the following. Everything else is 
just a warning. 

{noformat}
[javac] 
/home/ubuntu/cassandra/src/java/org/apache/cassandra/utils/Throwables.java:80: 
error: unreported exception Exception; must be caught or declared to be thrown
[javac] perform(Stream.of(actions));
[javac]^
{noformat}

Seems like javac isn't able to infer the types. Using an explicit declaration 
for the Stream.of() value will fix this. But now I'm getting [another 
issue|https://circleci.com/gh/spodkowinski/cassandra/123#tests/containers/3] 
saying that {{MoreExecutors.sameThreadExecutor())}} cannot be found. This seems 
to be due to [#492|https://github.com/google/error-prone/issues/492]. Again, 
the newer guava version used by errorprone breaks the build. -Why this isn't 
the case on my local machine is still beyond me; classpath issues I guess..- 
Edit: solved, use {{ant realclean}} to reproduce


was (Author: spo...@gmail.com):
The javac error that causes ant to fail is the following. Everything else is 
just a warning. 

{noformat}
[javac] 
/home/ubuntu/cassandra/src/java/org/apache/cassandra/utils/Throwables.java:80: 
error: unreported exception Exception; must be caught or declared to be thrown
[javac] perform(Stream.of(actions));
[javac]^
{noformat}

Seems like javac isn't able to infer the types. Using an explicit declaration 
for the Stream.of() value will fix this. But now I'm getting [another 
issue|https://circleci.com/gh/spodkowinski/cassandra/123#tests/containers/3] 
saying that {{MoreExecutors.sameThreadExecutor())}} cannot be found. This seems 
to be due to [#492|https://github.com/google/error-prone/issues/492]. Again, 
the newer guava version used by errorprone breaks the build. -Why this isn't 
the case on my local machine is still beyond me; classpath issues I guess..- 
Edit: solved, use {{ant realclean}}

> Integrate "Error Prone" Code Analyzer
> -
>
> Key: CASSANDRA-13175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: 0001-Add-Error-Prone-code-analyzer.patch, 
> checks-2_2.out, checks-3_0.out, checks-trunk.out
>
>
> I've been playing with [Error Prone|http://errorprone.info/] by integrating 
> it into the build process and to see what kind of warnings it would produce. 
> So far I'm positively impressed by the coverage and usefulness of some of the 
> implemented checks. See attachments for results.
> Unfortunately there are still some issues on how the analyzer is effecting 
> generated code and used guava versions, see 
> [#492|https://github.com/google/error-prone/issues/492]. In case those issues 
> have been solved and the resulting code isn't affected by the analyzer, I'd 
> suggest to add it to trunk with warn only behaviour and some less useful 
> checks disabled. Alternatively a new ant target could be added, maybe with 
> build breaking checks and CI integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-13175) Integrate "Error Prone" Code Analyzer

2017-09-07 Thread Stefan Podkowinski (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156931#comment-16156931
 ] 

Stefan Podkowinski edited comment on CASSANDRA-13175 at 9/7/17 1:18 PM:


The javac error that causes ant to fail is the following. Everything else is 
just a warning. 

{noformat}
[javac] 
/home/ubuntu/cassandra/src/java/org/apache/cassandra/utils/Throwables.java:80: 
error: unreported exception Exception; must be caught or declared to be thrown
[javac] perform(Stream.of(actions));
[javac]^
{noformat}

Seems like javac isn't able to infer the types. Using an explicit declaration 
for the Stream.of() value will fix this. But now I'm getting [another 
issue|https://circleci.com/gh/spodkowinski/cassandra/123#tests/containers/3] 
saying that {{MoreExecutors.sameThreadExecutor())}} cannot be found. This seems 
to be due to [#492|https://github.com/google/error-prone/issues/492]. Again, 
the newer guava version used by errorprone breaks the build. -Why this isn't 
the case on my local machine is still beyond me; classpath issues I guess..- 
Edit: solved, use {{ant realclean}}


was (Author: spo...@gmail.com):
The javac error that causes ant to fail is the following. Everything else is 
just a warning. 

{noformat}
[javac] 
/home/ubuntu/cassandra/src/java/org/apache/cassandra/utils/Throwables.java:80: 
error: unreported exception Exception; must be caught or declared to be thrown
[javac] perform(Stream.of(actions));
[javac]^
{noformat}

Seems like javac isn't able to infer the types. Using an explicit declaration 
for the Stream.of() value will fix this. But now I'm getting [another 
issue|https://circleci.com/gh/spodkowinski/cassandra/123#tests/containers/3] 
saying that {{MoreExecutors.sameThreadExecutor())}} cannot be found. This seems 
to be due to [#492|https://github.com/google/error-prone/issues/492]. Again, 
the newer guava version used by errorprone breaks the build. Why this isn't the 
case on my local machine is still beyond me; classpath issues I guess..


> Integrate "Error Prone" Code Analyzer
> -
>
> Key: CASSANDRA-13175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: 0001-Add-Error-Prone-code-analyzer.patch, 
> checks-2_2.out, checks-3_0.out, checks-trunk.out
>
>
> I've been playing with [Error Prone|http://errorprone.info/] by integrating 
> it into the build process and to see what kind of warnings it would produce. 
> So far I'm positively impressed by the coverage and usefulness of some of the 
> implemented checks. See attachments for results.
> Unfortunately there are still some issues on how the analyzer is effecting 
> generated code and used guava versions, see 
> [#492|https://github.com/google/error-prone/issues/492]. In case those issues 
> have been solved and the resulting code isn't affected by the analyzer, I'd 
> suggest to add it to trunk with warn only behaviour and some less useful 
> checks disabled. Alternatively a new ant target could be added, maybe with 
> build breaking checks and CI integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13175) Integrate "Error Prone" Code Analyzer

2017-09-07 Thread Stefan Podkowinski (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156931#comment-16156931
 ] 

Stefan Podkowinski commented on CASSANDRA-13175:


The javac error that causes ant to fail is the following. Everything else is 
just a warning. 

{noformat}
[javac] 
/home/ubuntu/cassandra/src/java/org/apache/cassandra/utils/Throwables.java:80: 
error: unreported exception Exception; must be caught or declared to be thrown
[javac] perform(Stream.of(actions));
[javac]^
{noformat}

Seems like javac isn't able to infer the types. Using an explicit declaration 
for the Stream.of() value will fix this. But now I'm getting [another 
issue|https://circleci.com/gh/spodkowinski/cassandra/123#tests/containers/3] 
saying that {{MoreExecutors.sameThreadExecutor())}} cannot be found. This seems 
to be due to [#492|https://github.com/google/error-prone/issues/492]. Again, 
the newer guava version used by errorprone breaks the build. Why this isn't the 
case on my local machine is still beyond me; classpath issues I guess..


> Integrate "Error Prone" Code Analyzer
> -
>
> Key: CASSANDRA-13175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: 0001-Add-Error-Prone-code-analyzer.patch, 
> checks-2_2.out, checks-3_0.out, checks-trunk.out
>
>
> I've been playing with [Error Prone|http://errorprone.info/] by integrating 
> it into the build process and to see what kind of warnings it would produce. 
> So far I'm positively impressed by the coverage and usefulness of some of the 
> implemented checks. See attachments for results.
> Unfortunately there are still some issues on how the analyzer is effecting 
> generated code and used guava versions, see 
> [#492|https://github.com/google/error-prone/issues/492]. In case those issues 
> have been solved and the resulting code isn't affected by the analyzer, I'd 
> suggest to add it to trunk with warn only behaviour and some less useful 
> checks disabled. Alternatively a new ant target could be added, maybe with 
> build breaking checks and CI integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13619) java.nio.BufferOverflowException: null while flushing hints

2017-09-07 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156907#comment-16156907
 ] 

Marcus Eriksson commented on CASSANDRA-13619:
-

[~milansm] could you post your schema and the modification statements you are 
running?

> java.nio.BufferOverflowException: null while flushing hints
> ---
>
> Key: CASSANDRA-13619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13619
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination, Core
>Reporter: Milan Milosevic
>
> I'm seeing the following exception running Cassandra 3.0.11 on 21 node 
> cluster in two AWS regions when half of the nodes in one region go down, and 
> the load is high on the rest of the nodes:
> {code}
> WARN  [SharedPool-Worker-10] 2017-06-14 12:57:15,017 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-10,5,main]: {}
> java.lang.RuntimeException: java.nio.BufferOverflowException
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2549)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0-zing_17.03.1.0]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.0.11.jar:3.0.11]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.11.jar:3.0.11]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0-zing_17.03.1.0]
> Caused by: java.nio.BufferOverflowException: null
> at 
> org.apache.cassandra.io.util.DataOutputBufferFixed.doFlush(DataOutputBufferFixed.java:52)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:195)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.writeUnsignedVInt(BufferedDataOutputStreamPlus.java:258)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Columns$Serializer.serialize(Columns.java:405) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.SerializationHeader$Serializer.serializeForMessaging(SerializationHeader.java:407)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:120)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serialize(PartitionUpdate.java:625)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serialize(Mutation.java:305)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.Hint$Serializer.serialize(Hint.java:141) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:251) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBuffer$Allocation.write(HintsBuffer.java:230) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsBufferPool.write(HintsBufferPool.java:61) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.hints.HintsService.write(HintsService.java:154) 
> ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$11.runMayThrow(StorageProxy.java:2627)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> at 
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2545)
>  ~[apache-cassandra-3.0.11.jar:3.0.11]
> ... 5 common frames omitted
> {code}
> Relevant configurations from cassandra.yaml:
> {code}
> -cassandra_hinted_handoff_throttle_in_kb: 1024
>  cassandra_max_hints_delivery_threads: 4
> -cassandra_hints_flush_period_in_ms: 1
> -cassandra_max_hints_file_size_in_mb: 512
> {code}
> When I reduce -cassandra_hints_flush_period_in_ms: 1 to 5000, the number 
> of exceptions lowers significantly, but they are still present.



--
This 

[jira] [Commented] (CASSANDRA-13831) NettyFactoryTest is failing in trunk on MacOS

2017-09-07 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156900#comment-16156900
 ] 

Aleksey Yeschenko commented on CASSANDRA-13831:
---

kk, just mark as Patch Available when ready.

> NettyFactoryTest is failing in trunk on MacOS
> -
>
> Key: CASSANDRA-13831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13831
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Aleksey Yeschenko
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 4.x
>
>
> Example failure:
> {code}
> [junit] Testcase: 
> getEventLoopGroup_EpollWithoutIoRatioBoost(org.apache.cassandra.net.async.NettyFactoryTest):
> Caused an ERROR
> [junit] failed to load the required native library
> [junit] java.lang.UnsatisfiedLinkError: failed to load the required 
> native library
> [junit]   at 
> io.netty.channel.epoll.Epoll.ensureAvailability(Epoll.java:78)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:53)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:134)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:35)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58)
> [junit]   at 
> io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:47)
> [junit]   at 
> io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:59)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:104)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
> [junit]   at 
> io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:68)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.getEventLoopGroup(NettyFactory.java:175)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Epoll(NettyFactoryTest.java:187)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_EpollWithoutIoRatioBoost(NettyFactoryTest.java:205)
> [junit] Caused by: java.lang.ExceptionInInitializerError
> [junit]   at io.netty.channel.epoll.Epoll.(Epoll.java:33)
> [junit]   at 
> org.apache.cassandra.service.NativeTransportService.useEpoll(NativeTransportService.java:162)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactory.(NettyFactory.java:94)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_Nio(NettyFactoryTest.java:216)
> [junit]   at 
> org.apache.cassandra.net.async.NettyFactoryTest.getEventLoopGroup_NioWithoutIoRatioBoost(NettyFactoryTest.java:211)
> [junit] Caused by: java.lang.IllegalStateException: Only supported on 
> Linux
> [junit]   at 
> io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:189)
> [junit]   at io.netty.channel.epoll.Native.(Native.java:61)
> {code}
> It's obviously caused by epoll being unavailable on MacOS, but the tests 
> should still be made to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13851) Allow existing nodes to use all peers in shadow round

2017-09-07 Thread Kurt Greaves (JIRA)
Kurt Greaves created CASSANDRA-13851:


 Summary: Allow existing nodes to use all peers in shadow round
 Key: CASSANDRA-13851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13851
 Project: Cassandra
  Issue Type: Bug
Reporter: Kurt Greaves


In CASSANDRA-10134 we made collision checks necessary on every startup. A 
side-effect was introduced that then requires a nodes seeds to be contacted on 
every startup. Prior to this change an existing node could start up regardless 
whether it could contact a seed node or not (because 
checkForEndpointCollision() was only called for bootstrapping nodes). 

Now if a nodes seeds are removed/deleted/fail it will no longer be able to 
start up until live seeds are configured (or itself is made a seed), even 
though it already knows about the rest of the ring. This is inconvenient for 
operators and has the potential to cause some nasty surprises and increase 
downtime.

One solution would be to use all a nodes existing peers as seeds in the shadow 
round. Not a Gossip guru though so not sure of implications.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13850) Modifying "cassandra-env.sh"

2017-09-07 Thread Amitkumar Ghatwal (JIRA)
Amitkumar Ghatwal created CASSANDRA-13850:
-

 Summary: Modifying "cassandra-env.sh"
 Key: CASSANDRA-13850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13850
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Amitkumar Ghatwal
 Fix For: 4.x


Hi All,

Added support for arch in "cassandra-env.sh " with PR  : 
https://github.com/apache/cassandra/pull/149

Regards,
Amit



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13782) Cassandra RPM has wrong owner for /usr/share directories

2017-09-07 Thread Stefan Podkowinski (JIRA)

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

Stefan Podkowinski updated CASSANDRA-13782:
---
   Resolution: Fixed
Fix Version/s: 2.1.19
   4.0
   3.11.1
   3.0.15
   2.2.11
   Status: Resolved  (was: Ready to Commit)

Merged as fc38c3835f276844bbd7a18 on 2.1 upwards

> Cassandra RPM has wrong owner for /usr/share directories
> 
>
> Key: CASSANDRA-13782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13782
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Hannu Kröger
>Assignee: Sasatani Takenobu
>  Labels: lhf
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0, 2.1.19
>
>
> Some Cassandra RPM directories are owned by cassandra user against the fedora 
> package guidelines.
> Offending lines: 
> https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L135-L136
> "Permissions on files MUST be set properly. Inside of /usr, files should be 
> owned by root:root unless a more specific user or group is needed for 
> security."
> - 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#File_Permissions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13782) Cassandra RPM has wrong owner for /usr/share directories

2017-09-07 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156678#comment-16156678
 ] 

ASF GitHub Bot commented on CASSANDRA-13782:


Github user spodkowinski commented on the issue:

https://github.com/apache/cassandra/pull/144
  
PR has been merged, thank you!


> Cassandra RPM has wrong owner for /usr/share directories
> 
>
> Key: CASSANDRA-13782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13782
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Hannu Kröger
>Assignee: Sasatani Takenobu
>  Labels: lhf
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0, 2.1.19
>
>
> Some Cassandra RPM directories are owned by cassandra user against the fedora 
> package guidelines.
> Offending lines: 
> https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L135-L136
> "Permissions on files MUST be set properly. Inside of /usr, files should be 
> owned by root:root unless a more specific user or group is needed for 
> security."
> - 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#File_Permissions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13782) Cassandra RPM has wrong owner for /usr/share directories

2017-09-07 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156675#comment-16156675
 ] 

ASF GitHub Bot commented on CASSANDRA-13782:


Github user asfgit closed the pull request at:

https://github.com/apache/cassandra/pull/144


> Cassandra RPM has wrong owner for /usr/share directories
> 
>
> Key: CASSANDRA-13782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13782
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Hannu Kröger
>Assignee: Sasatani Takenobu
>  Labels: lhf
>
> Some Cassandra RPM directories are owned by cassandra user against the fedora 
> package guidelines.
> Offending lines: 
> https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L135-L136
> "Permissions on files MUST be set properly. Inside of /usr, files should be 
> owned by root:root unless a more specific user or group is needed for 
> security."
> - 
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#File_Permissions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-09-07 Thread spod
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5dcb354c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5dcb354c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5dcb354c

Branch: refs/heads/cassandra-3.11
Commit: 5dcb354cc6888f2681b80f8f9b269afcfe97ddec
Parents: 90b39dc d34f479
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:21:04 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:21:17 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5dcb354c/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[03/15] cassandra git commit: RPM: Change owner to root except for /var

2017-09-07 Thread spod
RPM: Change owner to root except for /var

Closes #144
Patch by Sasatani Takenobu; reviewed by Stefan Podkowinski for CASSANDRA-13782


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc38c383
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc38c383
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc38c383

Branch: refs/heads/trunk
Commit: fc38c3835f276844bbd7a181301e92aabbd27d55
Parents: 5469f21
Author: sasayabaku 
Authored: Tue Aug 29 14:20:52 2017 +0900
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:17:34 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc38c383/redhat/cassandra.spec
--
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d87f760..05f1b0b 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -128,8 +128,8 @@ exit 0
 %attr(755,root,root) /%{_sysconfdir}/rc.d/init.d/%{username}
 %attr(755,root,root) /%{_sysconfdir}/default/%{username}
 %attr(755,root,root) /%{_sysconfdir}/security/limits.d/%{username}.conf
-%attr(755,%{username},%{username}) /usr/share/%{username}*
-%attr(755,%{username},%{username}) %config(noreplace) 
/%{_sysconfdir}/%{username}
+%attr(755,root,root) /usr/share/%{username}*
+%attr(755,root,root) %config(noreplace) /%{_sysconfdir}/%{username}
 %attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
 %attr(755,%{username},%{username}) /var/log/%{username}*
 %attr(755,%{username},%{username}) /var/run/%{username}*


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[15/15] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-09-07 Thread spod
Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e8b559ce
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e8b559ce
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e8b559ce

Branch: refs/heads/trunk
Commit: e8b559ce2f9e92f0a7a91fd60a4dcd6103793b43
Parents: dcef7c7 5dcb354
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:21:54 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:22:01 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e8b559ce/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[07/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-09-07 Thread spod
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8715c889
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8715c889
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8715c889

Branch: refs/heads/cassandra-2.2
Commit: 8715c889a77094f8fdcc65767453a20ea630f8ec
Parents: 4e834c5 fc38c38
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:18:21 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:01 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8715c889/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[08/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-09-07 Thread spod
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8715c889
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8715c889
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8715c889

Branch: refs/heads/cassandra-3.0
Commit: 8715c889a77094f8fdcc65767453a20ea630f8ec
Parents: 4e834c5 fc38c38
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:18:21 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:01 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8715c889/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[10/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-09-07 Thread spod
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d34f4795
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d34f4795
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d34f4795

Branch: refs/heads/trunk
Commit: d34f4795180897a20bc1d21954728ab6a88bfded
Parents: bc5c231 8715c88
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:20:40 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:47 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d34f4795/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-09-07 Thread spod
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5dcb354c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5dcb354c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5dcb354c

Branch: refs/heads/trunk
Commit: 5dcb354cc6888f2681b80f8f9b269afcfe97ddec
Parents: 90b39dc d34f479
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:21:04 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:21:17 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5dcb354c/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[05/15] cassandra git commit: RPM: Change owner to root except for /var

2017-09-07 Thread spod
RPM: Change owner to root except for /var

Closes #144
Patch by Sasatani Takenobu; reviewed by Stefan Podkowinski for CASSANDRA-13782


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc38c383
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc38c383
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc38c383

Branch: refs/heads/cassandra-3.11
Commit: fc38c3835f276844bbd7a181301e92aabbd27d55
Parents: 5469f21
Author: sasayabaku 
Authored: Tue Aug 29 14:20:52 2017 +0900
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:17:34 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc38c383/redhat/cassandra.spec
--
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d87f760..05f1b0b 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -128,8 +128,8 @@ exit 0
 %attr(755,root,root) /%{_sysconfdir}/rc.d/init.d/%{username}
 %attr(755,root,root) /%{_sysconfdir}/default/%{username}
 %attr(755,root,root) /%{_sysconfdir}/security/limits.d/%{username}.conf
-%attr(755,%{username},%{username}) /usr/share/%{username}*
-%attr(755,%{username},%{username}) %config(noreplace) 
/%{_sysconfdir}/%{username}
+%attr(755,root,root) /usr/share/%{username}*
+%attr(755,root,root) %config(noreplace) /%{_sysconfdir}/%{username}
 %attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
 %attr(755,%{username},%{username}) /var/log/%{username}*
 %attr(755,%{username},%{username}) /var/run/%{username}*


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[04/15] cassandra git commit: RPM: Change owner to root except for /var

2017-09-07 Thread spod
RPM: Change owner to root except for /var

Closes #144
Patch by Sasatani Takenobu; reviewed by Stefan Podkowinski for CASSANDRA-13782


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc38c383
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc38c383
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc38c383

Branch: refs/heads/cassandra-3.0
Commit: fc38c3835f276844bbd7a181301e92aabbd27d55
Parents: 5469f21
Author: sasayabaku 
Authored: Tue Aug 29 14:20:52 2017 +0900
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:17:34 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc38c383/redhat/cassandra.spec
--
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d87f760..05f1b0b 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -128,8 +128,8 @@ exit 0
 %attr(755,root,root) /%{_sysconfdir}/rc.d/init.d/%{username}
 %attr(755,root,root) /%{_sysconfdir}/default/%{username}
 %attr(755,root,root) /%{_sysconfdir}/security/limits.d/%{username}.conf
-%attr(755,%{username},%{username}) /usr/share/%{username}*
-%attr(755,%{username},%{username}) %config(noreplace) 
/%{_sysconfdir}/%{username}
+%attr(755,root,root) /usr/share/%{username}*
+%attr(755,root,root) %config(noreplace) /%{_sysconfdir}/%{username}
 %attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
 %attr(755,%{username},%{username}) /var/log/%{username}*
 %attr(755,%{username},%{username}) /var/run/%{username}*


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[01/15] cassandra git commit: RPM: Change owner to root except for /var

2017-09-07 Thread spod
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 5469f2120 -> fc38c3835
  refs/heads/cassandra-2.2 4e834c53c -> 8715c889a
  refs/heads/cassandra-3.0 bc5c2316c -> d34f47951
  refs/heads/cassandra-3.11 90b39dc61 -> 5dcb354cc
  refs/heads/trunk dcef7c7ed -> e8b559ce2


RPM: Change owner to root except for /var

Closes #144
Patch by Sasatani Takenobu; reviewed by Stefan Podkowinski for CASSANDRA-13782


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc38c383
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc38c383
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc38c383

Branch: refs/heads/cassandra-2.1
Commit: fc38c3835f276844bbd7a181301e92aabbd27d55
Parents: 5469f21
Author: sasayabaku 
Authored: Tue Aug 29 14:20:52 2017 +0900
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:17:34 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc38c383/redhat/cassandra.spec
--
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d87f760..05f1b0b 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -128,8 +128,8 @@ exit 0
 %attr(755,root,root) /%{_sysconfdir}/rc.d/init.d/%{username}
 %attr(755,root,root) /%{_sysconfdir}/default/%{username}
 %attr(755,root,root) /%{_sysconfdir}/security/limits.d/%{username}.conf
-%attr(755,%{username},%{username}) /usr/share/%{username}*
-%attr(755,%{username},%{username}) %config(noreplace) 
/%{_sysconfdir}/%{username}
+%attr(755,root,root) /usr/share/%{username}*
+%attr(755,root,root) %config(noreplace) /%{_sysconfdir}/%{username}
 %attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
 %attr(755,%{username},%{username}) /var/log/%{username}*
 %attr(755,%{username},%{username}) /var/run/%{username}*


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[12/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-09-07 Thread spod
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d34f4795
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d34f4795
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d34f4795

Branch: refs/heads/cassandra-3.0
Commit: d34f4795180897a20bc1d21954728ab6a88bfded
Parents: bc5c231 8715c88
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:20:40 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:47 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d34f4795/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[06/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-09-07 Thread spod
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8715c889
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8715c889
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8715c889

Branch: refs/heads/trunk
Commit: 8715c889a77094f8fdcc65767453a20ea630f8ec
Parents: 4e834c5 fc38c38
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:18:21 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:01 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8715c889/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[11/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-09-07 Thread spod
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d34f4795
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d34f4795
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d34f4795

Branch: refs/heads/cassandra-3.11
Commit: d34f4795180897a20bc1d21954728ab6a88bfded
Parents: bc5c231 8715c88
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:20:40 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:47 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d34f4795/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[09/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-09-07 Thread spod
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8715c889
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8715c889
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8715c889

Branch: refs/heads/cassandra-3.11
Commit: 8715c889a77094f8fdcc65767453a20ea630f8ec
Parents: 4e834c5 fc38c38
Author: Stefan Podkowinski 
Authored: Thu Sep 7 10:18:21 2017 +0200
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:20:01 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8715c889/redhat/cassandra.spec
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[02/15] cassandra git commit: RPM: Change owner to root except for /var

2017-09-07 Thread spod
RPM: Change owner to root except for /var

Closes #144
Patch by Sasatani Takenobu; reviewed by Stefan Podkowinski for CASSANDRA-13782


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc38c383
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc38c383
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc38c383

Branch: refs/heads/cassandra-2.2
Commit: fc38c3835f276844bbd7a181301e92aabbd27d55
Parents: 5469f21
Author: sasayabaku 
Authored: Tue Aug 29 14:20:52 2017 +0900
Committer: Stefan Podkowinski 
Committed: Thu Sep 7 10:17:34 2017 +0200

--
 redhat/cassandra.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc38c383/redhat/cassandra.spec
--
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index d87f760..05f1b0b 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -128,8 +128,8 @@ exit 0
 %attr(755,root,root) /%{_sysconfdir}/rc.d/init.d/%{username}
 %attr(755,root,root) /%{_sysconfdir}/default/%{username}
 %attr(755,root,root) /%{_sysconfdir}/security/limits.d/%{username}.conf
-%attr(755,%{username},%{username}) /usr/share/%{username}*
-%attr(755,%{username},%{username}) %config(noreplace) 
/%{_sysconfdir}/%{username}
+%attr(755,root,root) /usr/share/%{username}*
+%attr(755,root,root) %config(noreplace) /%{_sysconfdir}/%{username}
 %attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
 %attr(755,%{username},%{username}) /var/log/%{username}*
 %attr(755,%{username},%{username}) /var/run/%{username}*


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Assigned] (CASSANDRA-13847) test failure in cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login

2017-09-07 Thread JIRA

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

Andrés de la Peña reassigned CASSANDRA-13847:
-

Assignee: Andrés de la Peña

> test failure in 
> cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login
> 
>
> Key: CASSANDRA-13847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13847
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing, Tools
>Reporter: Joel Knighton
>Assignee: Andrés de la Peña
>  Labels: test-failure
> Fix For: 2.1.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/546/testReport/cqlsh_tests.cqlsh_tests/CqlLoginTest/test_list_roles_after_login
> This test was added for [CASSANDRA-13640]. The comments seem to indicated 
> this is only a problem on 3.0+, but the added test certainly seems to 
> reproduce the problem on 2.1 and 2.2. Even if the issue does affect 2.1/2.2, 
> it seems insufficiently critical for 2.1, so we need to limit the test to run 
> on 2.2+ at the very least, possibly 3.0+ if we don't fix the cause on 2.2.
> Thoughts [~adelapena]?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-13847) test failure in cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login

2017-09-07 Thread JIRA

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156651#comment-16156651
 ] 

Andrés de la Peña commented on CASSANDRA-13847:
---

Right, the bug also affects 2.1 and 2.2.

Here is the patch to solve it in 2.2 and the patch for dtests with the 
{{@since}} tag:
||[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...adelapena:13847-2.2]||[dtest|https://github.com/apache/cassandra-dtest/compare/master...adelapena:13847]||

Regarding 2.1, I agree this is indeed insufficiently critical, and there's a 
clear workaround (exiting cqlsh and logging back).

> test failure in 
> cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login
> 
>
> Key: CASSANDRA-13847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13847
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing, Tools
>Reporter: Joel Knighton
>  Labels: test-failure
> Fix For: 2.1.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/546/testReport/cqlsh_tests.cqlsh_tests/CqlLoginTest/test_list_roles_after_login
> This test was added for [CASSANDRA-13640]. The comments seem to indicated 
> this is only a problem on 3.0+, but the added test certainly seems to 
> reproduce the problem on 2.1 and 2.2. Even if the issue does affect 2.1/2.2, 
> it seems insufficiently critical for 2.1, so we need to limit the test to run 
> on 2.2+ at the very least, possibly 3.0+ if we don't fix the cause on 2.2.
> Thoughts [~adelapena]?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13847) test failure in cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login

2017-09-07 Thread JIRA

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

Andrés de la Peña updated CASSANDRA-13847:
--
Fix Version/s: 2.1.x
   Status: Patch Available  (was: Open)

> test failure in 
> cqlsh_tests.cqlsh_tests.CqlLoginTest.test_list_roles_after_login
> 
>
> Key: CASSANDRA-13847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13847
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing, Tools
>Reporter: Joel Knighton
>  Labels: test-failure
> Fix For: 2.1.x
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/546/testReport/cqlsh_tests.cqlsh_tests/CqlLoginTest/test_list_roles_after_login
> This test was added for [CASSANDRA-13640]. The comments seem to indicated 
> this is only a problem on 3.0+, but the added test certainly seems to 
> reproduce the problem on 2.1 and 2.2. Even if the issue does affect 2.1/2.2, 
> it seems insufficiently critical for 2.1, so we need to limit the test to run 
> on 2.2+ at the very least, possibly 3.0+ if we don't fix the cause on 2.2.
> Thoughts [~adelapena]?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-13849) GossipStage blocks because of race in ActiveRepairService

2017-09-07 Thread Tom van der Woerdt (JIRA)
Tom van der Woerdt created CASSANDRA-13849:
--

 Summary: GossipStage blocks because of race in ActiveRepairService
 Key: CASSANDRA-13849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13849
 Project: Cassandra
  Issue Type: Bug
Reporter: Tom van der Woerdt


Bad luck caused a kernel panic in a cluster, and that took another node with it 
because GossipStage stopped responding.

I think it's pretty obvious what's happening, here are the relevant excerpts 
from the stack traces :

{noformat}
"Thread-24004" #393781 daemon prio=5 os_prio=0 tid=0x7efca9647400 
nid=0xe75c waiting on condition [0x7efaa47fe000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x00052b63a7e8> (a 
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:332)
- locked <0x0002e6bc99f0> (a 
org.apache.cassandra.service.ActiveRepairService)
at 
org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:211)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  

 at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at 
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$3/1498438472.run(Unknown
 Source)
at java.lang.Thread.run(Thread.java:748)

"GossipTasks:1" #367 daemon prio=5 os_prio=0 tid=0x7efc5e971000 nid=0x700b 
waiting for monitor entry [0x7dfb839fe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.service.ActiveRepairService.removeParentRepairSession(ActiveRepairService.java:421)
- waiting to lock <0x0002e6bc99f0> (a 
org.apache.cassandra.service.ActiveRepairService)
at 
org.apache.cassandra.service.ActiveRepairService.convict(ActiveRepairService.java:776)
at 
org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:306)
at org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:775)   

 at 
org.apache.cassandra.gms.Gossiper.access$800(Gossiper.java:67)
at org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:187)
at 
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at 
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$3/1498438472.run(Unknown
 Source)
at java.lang.Thread.run(Thread.java:748)

"GossipStage:1" #320 daemon prio=5 os_prio=0 tid=0x7efc5b9f2c00 nid=0x6fcd 
waiting for monitor entry [0x7e260186a000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.cassandra.service.ActiveRepairService.removeParentRepairSession(ActiveRepairService.java:421)
- waiting to lock <0x0002e6bc99f0> (a 
org.apache.cassandra.service.ActiveRepairService)   
   at 
org.apache.cassandra.service.ActiveRepairService.convict(ActiveRepairService.java:776)
at 
org.apache.cassandra.service.ActiveRepairService.onRestart(ActiveRepairService.java:744)
at 
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1049)
at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1143)
at 

[jira] [Commented] (CASSANDRA-13175) Integrate "Error Prone" Code Analyzer

2017-09-07 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156593#comment-16156593
 ] 

Marcus Eriksson commented on CASSANDRA-13175:
-

the error is because {{ant errorprone}} does not generate a junit xml which we 
try to collect later, fix 
[here|https://github.com/krummas/cassandra/commit/2beae60a1189b90515f093ef46fa4214e529f187]
 - circle running [here|https://circleci.com/gh/krummas/cassandra/107]

> Integrate "Error Prone" Code Analyzer
> -
>
> Key: CASSANDRA-13175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13175
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: 0001-Add-Error-Prone-code-analyzer.patch, 
> checks-2_2.out, checks-3_0.out, checks-trunk.out
>
>
> I've been playing with [Error Prone|http://errorprone.info/] by integrating 
> it into the build process and to see what kind of warnings it would produce. 
> So far I'm positively impressed by the coverage and usefulness of some of the 
> implemented checks. See attachments for results.
> Unfortunately there are still some issues on how the analyzer is effecting 
> generated code and used guava versions, see 
> [#492|https://github.com/google/error-prone/issues/492]. In case those issues 
> have been solved and the resulting code isn't affected by the analyzer, I'd 
> suggest to add it to trunk with warn only behaviour and some less useful 
> checks disabled. Alternatively a new ant target could be added, maybe with 
> build breaking checks and CI integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-12014) IndexSummary > 2G causes an assertion error

2017-09-07 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156565#comment-16156565
 ] 

Marcus Eriksson commented on CASSANDRA-12014:
-

the simplified patch looks good to me (rebased and pushed 
[here|https://github.com/krummas/cassandra/commits/stefania/12014]) 
dtests: 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/288/
unit tests: https://circleci.com/gh/krummas/cassandra/106

> IndexSummary > 2G causes an assertion error
> ---
>
> Key: CASSANDRA-12014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12014
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.0.x, 3.11.x
>
>
> {noformat}
> ERROR [CompactionExecutor:1546280] 2016-06-01 13:21:00,444  
> CassandraDaemon.java:229 - Exception in thread 
> Thread[CompactionExecutor:1546280,1,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.maybeAddEntry(IndexSummaryBuilder.java:171)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.append(SSTableWriter.java:634)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.afterAppend(SSTableWriter.java:179)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:205) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {noformat}
> I believe this can be fixed by raising the min_index_interval, but we should 
> have a better method of coping with this than throwing the AE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org