[jira] [Commented] (CASSANDRA-12220) utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure

2016-07-17 Thread Dave Brosius (JIRA) 

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

Dave Brosius commented on CASSANDRA-12220:
--

odd. obstensibly, the difference is in 

UnfilteredSerializer.serializeRowBody

where in the broken case, the row has column [ck], when it should have column 
[val]

Thus the BTreeSearchIterator can't find it, and returns null

for (ColumnData data : row)
{
ColumnDefinition column = si.next(data.column());



looking...

> utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
> --
>
> Key: CASSANDRA-12220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12220
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>
> The unit tests {{RowIndexEntryTest.testC11206AgainstPreviousArray}} and 
> {{RowIndexEntryTest.testC11206AgainstPreviousShallow}} fail after [this 
> single line 
> change|https://github.com/apache/cassandra/commit/70fd80ae43f3902e651c956b6d4d07cbc203d30a#diff-75146ba408a51071a0b19ffdfbb2bb3cL307]
>  as shown in [this 
> build|http://cassci.datastax.com/view/trunk/job/trunk_testall/1044/].
> Reverting that line to {{new HashMap<>()}} fixes the unit test issues - but 
> _does not_ explain why it fails, since initializing a collection with the 
> expected size should not change the overall behaviour. There seems to be 
> something else being wrong.
> /cc [~dbrosius]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12221) Maximum Memory Usage Reached - NoSpamLogger

2016-07-17 Thread vin01 (JIRA) 

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

vin01 commented on CASSANDRA-12221:
---

Thanks.

So shouldn't it be a WARN/ERROR? does it cause any issues ? can it be 
responsible for High CPU Usage?

> Maximum Memory Usage Reached - NoSpamLogger
> ---
>
> Key: CASSANDRA-12221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12221
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.8 x86_64, Cassandra-3.0.7
>Reporter: vin01
>Priority: Minor
>
> I see some logs which look like :-
> INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> When i get these logs, CPU usage is quite high on the system.
> Are they expected? Log message also seems confusing and i am not sure what 
> memory we are talking about here..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12221) Maximum Memory Usage Reached - NoSpamLogger

2016-07-17 Thread Wei Deng (JIRA) 

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

Wei Deng commented on CASSANDRA-12221:
--

See CASSANDRA-5661. It's a cap to limit the amount of off-heap memory used by 
RandomAccessReader, and if there is a need, you can change the limit by 
file_cache_size_in_mb in cassandra.yaml.

> Maximum Memory Usage Reached - NoSpamLogger
> ---
>
> Key: CASSANDRA-12221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12221
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.8 x86_64, Cassandra-3.0.7
>Reporter: vin01
>Priority: Minor
>
> I see some logs which look like :-
> INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> When i get these logs, CPU usage is quite high on the system.
> Are they expected? Log message also seems confusing and i am not sure what 
> memory we are talking about here..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12221) Maximum Memory Usage Reached - NoSpamLogger

2016-07-17 Thread vin01 (JIRA) 

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

vin01 updated CASSANDRA-12221:
--
Description: 
I see some logs which look like :-

INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes

When i get these logs, CPU usage is quite high on the system.
Are they expected? Log message also seems confusing and i am not sure what 
memory we are talking about here..

  was:
I see some logs which look like :-

INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes

When i see these logs, CPU usage is quite high on the system.
Are they expected? Log message also seems confusing and i am not sure what 
memory we are talking about here..


> Maximum Memory Usage Reached - NoSpamLogger
> ---
>
> Key: CASSANDRA-12221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12221
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: CentOS 6.8 x86_64, Cassandra-3.0.7
>Reporter: vin01
>Priority: Minor
>
> I see some logs which look like :-
> INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
> Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
> 1048576 bytes
> When i get these logs, CPU usage is quite high on the system.
> Are they expected? Log message also seems confusing and i am not sure what 
> memory we are talking about here..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12221) Maximum Memory Usage Reached - NoSpamLogger

2016-07-17 Thread vin01 (JIRA) 
vin01 created CASSANDRA-12221:
-

 Summary: Maximum Memory Usage Reached - NoSpamLogger
 Key: CASSANDRA-12221
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12221
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: CentOS 6.8 x86_64, Cassandra-3.0.7
Reporter: vin01
Priority: Minor


I see some logs which look like :-

INFO  [SharedPool-Worker-22] 2016-07-17 22:03:02,725 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-33] 2016-07-17 22:18:02,747 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-35] 2016-07-17 22:33:02,829 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes
INFO  [SharedPool-Worker-31] 2016-07-17 22:48:02,834 NoSpamLogger.java:91 - 
Maximum memory usage reached (536870912 bytes), cannot allocate chunk of 
1048576 bytes

When i see these logs, CPU usage is quite high on the system.
Are they expected? Log message also seems confusing and i am not sure what 
memory we are talking about here..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12220) utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure

2016-07-17 Thread Robert Stupp (JIRA) 
Robert Stupp created CASSANDRA-12220:


 Summary: utest 
RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
 Key: CASSANDRA-12220
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12220
 Project: Cassandra
  Issue Type: Bug
Reporter: Robert Stupp


The unit tests {{RowIndexEntryTest.testC11206AgainstPreviousArray}} and 
{{RowIndexEntryTest.testC11206AgainstPreviousShallow}} fail after [this single 
line 
change|https://github.com/apache/cassandra/commit/70fd80ae43f3902e651c956b6d4d07cbc203d30a#diff-75146ba408a51071a0b19ffdfbb2bb3cL307]
 as shown in [this 
build|http://cassci.datastax.com/view/trunk/job/trunk_testall/1044/].

Reverting that line to {{new HashMap<>()}} fixes the unit test issues - but 
_does not_ explain why it fails, since initializing a collection with the 
expected size should not change the overall behaviour. There seems to be 
something else being wrong.

/cc [~dbrosius]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11465) dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test

2016-07-17 Thread Stefania (JIRA) 

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

Stefania commented on CASSANDRA-11465:
--

The last 2 runs of dtests were successful. I've rebased and launched both 
dtests and utests one more time. If the results are again successful, we can 
move on to repeating a few runs of only {{cqlsh_tracing_test.TestCqlTracing}} 
on Jenkins (i.e. 20x) and reviewing the patch.

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
> --
>
> Key: CASSANDRA-11465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11465
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
>
> Failing on the following assert, on trunk only: 
> {{self.assertEqual(len(errs[0]), 1)}}
> Is not failing consistently.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1087/testReport/cql_tracing_test/TestCqlTracing/tracing_unknown_impl_test
> Failed on CassCI build trunk_dtest #1087



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12214) cqlshlib test failure: cqlshlib.test.remove_test_db

2016-07-17 Thread Stefania (JIRA) 

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

Stefania edited comment on CASSANDRA-12214 at 7/18/16 3:22 AM:
---

The failures in test_complete_in_create_* are caused by CDC changes and the fix 
is coming in CASSANDRA-11850.

{{remove_test_db}} is not a test, it is a method invoked when a test is 
completed in order to drop the test keyspace. It failed with a client request 
timeout with cython=yes but I cannot reproduce it locally, or on Jenkins with 
the 11850 branch. I think it may be failing only when some other tests are 
failing, but I am not entirely sure. Let's see if it continues failing once 
11850 is committed.


was (Author: stefania):
The failures in test_complete_in_create_* are caused by CDC changes and the fix 
is coming in CASSANDRA-11850.

{{remove_test_db}} is not a test, it is a method invoked when a test is 
completed in order to drop the test keyspace. It failed with a client request 
timeout with cython=yes but I cannot reproduce it locally, or on Jenkins with 
the 11850 branch. I think it may be failing only when some other tests are 
failing, but I am not entirely sure. Let's see if it continue failing once 
11850 is committed.

>  cqlshlib test failure: cqlshlib.test.remove_test_db
> 
>
> Key: CASSANDRA-12214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12214
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>  Labels: cqlsh
>
> [~Stefania]  
> http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/lastCompletedBuild/testReport/
> Hello, these three tests are failing:
> cqlshlib.test.remove_test_db
> cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_columnfamily
> cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_table
> Can you look at them, please?  Thank you!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12214) cqlshlib test failure: cqlshlib.test.remove_test_db

2016-07-17 Thread Stefania (JIRA) 

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

Stefania commented on CASSANDRA-12214:
--

The failures in test_complete_in_create_* are caused by CDC changes and the fix 
is coming in CASSANDRA-11850.

{{remove_test_db}} is not a test, it is a method invoked when a test is 
completed in order to drop the test keyspace. It failed with a client request 
timeout with cython=yes but I cannot reproduce it locally, or on Jenkins with 
the 11850 branch. I think it may be failing only when some other tests are 
failing, but I am not entirely sure. Let's see if it continue failing once 
11850 is committed.

>  cqlshlib test failure: cqlshlib.test.remove_test_db
> 
>
> Key: CASSANDRA-12214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12214
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>  Labels: cqlsh
>
> [~Stefania]  
> http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/lastCompletedBuild/testReport/
> Hello, these three tests are failing:
> cqlshlib.test.remove_test_db
> cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_columnfamily
> cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion.test_complete_in_create_table
> Can you look at them, please?  Thank you!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

2016-07-17 Thread Stefania (JIRA) 

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

Stefania commented on CASSANDRA-9318:
-

I'm happy with the suggested way forward. It removes exceptions and it makes 
the rate based strategy more tunable rather than forcing everything to the 
slowest replica rate. 

The proposal doesn't address:

bq. The API should provide for reporting load to clients so they can do real 
load balancing across coordinators and not just round-robin.

However, we can add metrics or another mechanism later on in follow up tickets, 
as well as consider implementing the memory-threshold strategy.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12212) system.compactions_in_progress needs to be used on first upgrade to 3.0

2016-07-17 Thread Stefania (JIRA) 

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

Stefania commented on CASSANDRA-12212:
--

Was there an actual problem caused by this? We delete unfinished temporary 
files in {{SystemKeyspace.migrateDataDirs()}}.

As for final files, consulting {{system.compactions_in_progress}} would only 
partially help because the old files still exist when the entry in the table is 
deleted by {{CompactionTask.runMyThrow()}}. There is a time interval between 
temporary new files being promoted to final new files and the deletion of the 
entry in the table, this would be protected, but the time interval between the 
deletion of the entry and the deletion of old files (which could be much longer 
if other references to the sstables exist) is not protected. As far as it was 
understood during the development of 7066, the only adverse effect of this is a 
redundant compaction since counters no longer double-count in 2.1.

Further, since CASSANDRA-10079 we also cancel compactions in progress in 
nodetool drain, so if people follow the upgrade procedure there won't be any 
entry in the table or left-overs on disk.

> system.compactions_in_progress needs to be used on first upgrade to 3.0
> ---
>
> Key: CASSANDRA-12212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12212
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeremiah Jordan
>Assignee: Stefania
> Fix For: 3.0.x, 3.x
>
>
> CASSANDRA-7066 removed the system.compactions_in_progress table and replaced 
> it with the new transaction system.  But system.compactions_in_progress needs 
> to be consulted for the first startup after upgrading from 2.1 to 3.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception

2016-07-17 Thread Robert Stupp (JIRA) 

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

Robert Stupp commented on CASSANDRA-12181:
--

Alright - kicked off CI for 3.0 + trunk:
||cassandra-3.0|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:12181-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-3.0-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-3.0-dtest/lastSuccessfulBuild/]
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12181-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12181-trunk-dtest/lastSuccessfulBuild/]

> Include table name in "Cannot get comparator" exception
> ---
>
> Key: CASSANDRA-12181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12181
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0.txt
>
>
> Having table name will help in debugging the following exception. 
> ERROR [MutationStage:xx]  CassandraDaemon.java (line 199) Exception in thread 
> Thread[MutationStage:3788,5,main]
> clusterName=itms8shared20
> java.lang.RuntimeException: Cannot get comparator 2 in 
> org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type).
>  
> This might be due to a mismatch between the schema and the data read



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: avoid double map lookup in loop

2016-07-17 Thread dbrosius 
Repository: cassandra
Updated Branches:
  refs/heads/trunk 70fd80ae4 -> 0a5603789


avoid double map lookup in loop


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

Branch: refs/heads/trunk
Commit: 0a5603789d09a946a22f6928269590c284d80e40
Parents: 70fd80a
Author: Dave Brosius 
Authored: Sun Jul 17 19:40:15 2016 -0400
Committer: Dave Brosius 
Committed: Sun Jul 17 19:40:15 2016 -0400

--
 .../cassandra/db/compaction/LeveledCompactionStrategy.java   | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a560378/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java 
b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
index 3f57fe0..ec5e1d9 100644
--- a/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
+++ b/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
@@ -179,11 +179,13 @@ public class LeveledCompactionStrategy extends 
AbstractCompactionStrategy
 for (SSTableReader sstable : ssTablesToGroup)
 {
 Integer level = sstable.getSSTableLevel();
-if (!sstablesByLevel.containsKey(level))
+Collection sstablesForLevel = 
sstablesByLevel.get(level);
+if (sstablesForLevel == null)
 {
-sstablesByLevel.put(level, new ArrayList());
+sstablesForLevel = new ArrayList();
+sstablesByLevel.put(level, sstablesForLevel);
 }
-sstablesByLevel.get(level).add(sstable);
+sstablesForLevel.add(sstable);
 }
 
 Collection groupedSSTables = new 
ArrayList<>();

cassandra git commit: presize collections

2016-07-17 Thread dbrosius 
Repository: cassandra
Updated Branches:
  refs/heads/trunk 087264f29 -> 70fd80ae4


presize collections


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

Branch: refs/heads/trunk
Commit: 70fd80ae43f3902e651c956b6d4d07cbc203d30a
Parents: 087264f
Author: Dave Brosius 
Authored: Sun Jul 17 19:28:04 2016 -0400
Committer: Dave Brosius 
Committed: Sun Jul 17 19:28:04 2016 -0400

--
 src/java/org/apache/cassandra/config/CFMetaData.java| 5 +++--
 .../org/apache/cassandra/cql3/statements/BatchStatement.java| 3 ++-
 .../apache/cassandra/cql3/statements/CreateIndexStatement.java  | 3 ++-
 .../apache/cassandra/cql3/statements/CreateViewStatement.java   | 3 ++-
 .../org/apache/cassandra/db/compaction/CompactionManager.java   | 2 +-
 5 files changed, 10 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/70fd80ae/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java 
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 4de4f7b..b175ef1c 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -32,6 +32,7 @@ import com.google.common.base.MoreObjects;
 import com.google.common.base.Objects;
 import com.google.common.collect.ImmutableSet;
 import com.google.common.collect.Iterables;
+import com.google.common.collect.Maps;
 import com.google.common.collect.Sets;
 import org.apache.commons.lang3.ArrayUtils;
 import org.apache.commons.lang3.builder.HashCodeBuilder;
@@ -304,7 +305,7 @@ public final class CFMetaData
 {
 this.comparator = new 
ClusteringComparator(extractTypes(clusteringColumns));
 
-Map newColumnMetadata = new HashMap<>();
+Map newColumnMetadata = 
Maps.newHashMapWithExpectedSize(partitionKeyColumns.size() + 
clusteringColumns.size() + partitionColumns.size());
 for (ColumnDefinition def : partitionKeyColumns)
 newColumnMetadata.put(def.name.bytes, def);
 for (ColumnDefinition def : clusteringColumns)
@@ -1260,7 +1261,7 @@ public final class CFMetaData
 
 public Set usedColumnNames()
 {
-Set usedNames = new HashSet<>();
+Set usedNames = 
Sets.newHashSetWithExpectedSize(partitionKeys.size() + clusteringColumns.size() 
+ staticColumns.size() + regularColumns.size());
 for (Pair p : partitionKeys)
 usedNames.add(p.left.toString());
 for (Pair p : clusteringColumns)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/70fd80ae/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 2739c2e..14638e2 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -22,6 +22,7 @@ import java.util.*;
 import java.util.concurrent.TimeUnit;
 
 import com.google.common.collect.Iterables;
+import com.google.common.collect.Maps;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 import org.slf4j.helpers.MessageFormatter;
@@ -554,7 +555,7 @@ public class BatchStatement implements CQLStatement
 
 public Map build()
 {
-Map m = new HashMap<>();
+Map m = 
Maps.newHashMapWithExpectedSize(perTableBuilders.size());
 for (Map.Entry p : 
perTableBuilders.entrySet())
 m.put(p.getKey(), p.getValue().build());
 return m;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/70fd80ae/src/java/org/apache/cassandra/cql3/statements/CreateIndexStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/CreateIndexStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/CreateIndexStatement.java
index f899247..2526f79 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateIndexStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateIndexStatement.java
@@ -22,6 +22,7 @@ import java.util.*;

[jira] [Comment Edited] (CASSANDRA-12209) Make Level compaction default

2016-07-17 Thread Jeff Jirsa (JIRA) 

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

Jeff Jirsa edited comment on CASSANDRA-12209 at 7/17/16 11:20 PM:
--

Middle ground seems better (though since it's impractical to guarantee all 
nodes in the cluster have the same yaml/system property settings, a user who 
mixes values may get some surprises - that's on them, though).



was (Author: jjirsa):
Middle ground seems better (though since it's impossible to guarantee all nodes 
in the cluster have the same yaml/system property settings, a user who mixes 
values may get some surprises - that's on them, though).


> Make Level compaction default
> -
>
> Key: CASSANDRA-12209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12209
> Project: Cassandra
>  Issue Type: Wish
>Reporter: sankalp kohli
>Priority: Minor
>
>  Level Compaction has come a long way since it was added. I think it is time 
> to make it default. We can debate which version we can do this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12209) Make Level compaction default

2016-07-17 Thread Jeff Jirsa (JIRA) 

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

Jeff Jirsa commented on CASSANDRA-12209:


Middle ground seems better (though since it's impossible to guarantee all nodes 
in the cluster have the same yaml/system property settings, a user who mixes 
values may get some surprises - that's on them, though).


> Make Level compaction default
> -
>
> Key: CASSANDRA-12209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12209
> Project: Cassandra
>  Issue Type: Wish
>Reporter: sankalp kohli
>Priority: Minor
>
>  Level Compaction has come a long way since it was added. I think it is time 
> to make it default. We can debate which version we can do this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli updated CASSANDRA-12179:
--
Status: Patch Available  (was: Open)

> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop 
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not 
> require a bounce. This is useful for large clusters where we can change this 
> value and see the impact. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli commented on CASSANDRA-12179:
---

Attached v2. I am not sure how I can get access to DynamicEndpointSnitch object 
without instance of check. 

> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop 
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not 
> require a bounce. This is useful for large clusters where we can change this 
> value and see the impact. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12179) Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli updated CASSANDRA-12179:
--
Attachment: CASSANDRA-12179-3.0_v2.txt

> Make DynamicEndpointSnitch dynamic_snitch_update_interval_in_ms a JMX Prop 
> ---
>
> Key: CASSANDRA-12179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12179
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.x
>
> Attachments: CASSANDRA-12179-3.0_v2.txt, CASSANDRA-12179_3.0.txt
>
>
> Need to expose dynamic_snitch_update_interval_in_ms so that it does not 
> require a bounce. This is useful for large clusters where we can change this 
> value and see the impact. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli updated CASSANDRA-12181:
--
Status: Patch Available  (was: Open)

> Include table name in "Cannot get comparator" exception
> ---
>
> Key: CASSANDRA-12181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12181
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0.txt
>
>
> Having table name will help in debugging the following exception. 
> ERROR [MutationStage:xx]  CassandraDaemon.java (line 199) Exception in thread 
> Thread[MutationStage:3788,5,main]
> clusterName=itms8shared20
> java.lang.RuntimeException: Cannot get comparator 2 in 
> org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type).
>  
> This might be due to a mismatch between the schema and the data read



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli commented on CASSANDRA-12181:
---

v2 attached

> Include table name in "Cannot get comparator" exception
> ---
>
> Key: CASSANDRA-12181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12181
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0.txt
>
>
> Having table name will help in debugging the following exception. 
> ERROR [MutationStage:xx]  CassandraDaemon.java (line 199) Exception in thread 
> Thread[MutationStage:3788,5,main]
> clusterName=itms8shared20
> java.lang.RuntimeException: Cannot get comparator 2 in 
> org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type).
>  
> This might be due to a mismatch between the schema and the data read



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli updated CASSANDRA-12181:
--
Attachment: CASSANDRA-12181-3.0_v2.txt

> Include table name in "Cannot get comparator" exception
> ---
>
> Key: CASSANDRA-12181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12181
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0.txt
>
>
> Having table name will help in debugging the following exception. 
> ERROR [MutationStage:xx]  CassandraDaemon.java (line 199) Exception in thread 
> Thread[MutationStage:3788,5,main]
> clusterName=itms8shared20
> java.lang.RuntimeException: Cannot get comparator 2 in 
> org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type).
>  
> This might be due to a mismatch between the schema and the data read



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12209) Make Level compaction default

2016-07-17 Thread sankalp kohli (JIRA) 

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

sankalp kohli commented on CASSANDRA-12209:
---

+1 for [~jasobrown] suggestion 

> Make Level compaction default
> -
>
> Key: CASSANDRA-12209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12209
> Project: Cassandra
>  Issue Type: Wish
>Reporter: sankalp kohli
>Priority: Minor
>
>  Level Compaction has come a long way since it was added. I think it is time 
> to make it default. We can debate which version we can do this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12209) Make Level compaction default

2016-07-17 Thread Jason Brown (JIRA) 

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

Jason Brown edited comment on CASSANDRA-12209 at 7/17/16 12:54 PM:
---

As a middle ground, could we make it configurable? It could become an 
'unadvertized' setting, either as a {{-D}} param to the jvm or a yaml entry 
that we don't bother to put into the default {{conf/cassandra.yaml}} (with 
{{Config}} initiailizing to the default).


was (Author: jasobrown):
As a middle ground, could we make it configurable? It could become an 
'unadvertized' setting, either as a {{-D}} param to the jvm or a yaml entry 
that we don't bother to put into default {{conf/cassandra.yaml}}.

> Make Level compaction default
> -
>
> Key: CASSANDRA-12209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12209
> Project: Cassandra
>  Issue Type: Wish
>Reporter: sankalp kohli
>Priority: Minor
>
>  Level Compaction has come a long way since it was added. I think it is time 
> to make it default. We can debate which version we can do this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12209) Make Level compaction default

2016-07-17 Thread Jason Brown (JIRA) 

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

Jason Brown commented on CASSANDRA-12209:
-

As a middle ground, could we make it configurable? It could become an 
'unadvertized' setting, either as a {{-D}} param to the jvm or a yaml entry 
that we don't bother to put into default {{conf/cassandra.yaml}}.

> Make Level compaction default
> -
>
> Key: CASSANDRA-12209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12209
> Project: Cassandra
>  Issue Type: Wish
>Reporter: sankalp kohli
>Priority: Minor
>
>  Level Compaction has come a long way since it was added. I think it is time 
> to make it default. We can debate which version we can do this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)