[jira] [Commented] (CASSANDRA-13259) Use platform specific X.509 default algorithm

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13259:


Rebased the first patch submitted when creating this ticket:

||trunk||
|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13259-trunk]|
|[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/494/]|
|[unit_tests|https://circleci.com/gh/spodkowinski/cassandra/223]|


> Use platform specific X.509 default algorithm
> -
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE 
> default instead. This implementation will currently not work on less popular 
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14055) Index redistribution breaks SASI index

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-14055:

Fix Version/s: 4.x
Reproduced In: 3.11.1, 3.10  (was: 3.10, 3.11.1)
   Status: Patch Available  (was: Open)

> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x, 4.x
>
> Attachments: CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch, CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14055) Index redistribution breaks SASI index

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-14055:

Reproduced In: 3.11.1, 3.10  (was: 3.10, 3.11.1)
   Status: Open  (was: Ready to Commit)

> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x, 4.x
>
> Attachments: CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch, CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14210) Optimize SSTables upgrade task scheduling

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-14210:

Reproduced In: 3.0.15, 2.2.11  (was: 2.2.11, 3.0.15)
 Reviewer: Marcus Eriksson

> Optimize SSTables upgrade task scheduling
> -
>
> Key: CASSANDRA-14210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14210
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Oleksandr Shulgin
>Assignee: Kurt Greaves
>Priority: Major
> Fix For: 4.x
>
>
> When starting the SSTable-rewrite process by running {{nodetool 
> upgradesstables --jobs N}}, with N > 1, not all of the provided N slots are 
> used.
> For example, we were testing with {{concurrent_compactors=5}} and {{N=4}}.  
> What we observed both for version 2.2 and 3.0, is that initially all 4 
> provided slots are used for "Upgrade sstables" compactions, but later when 
> some of the 4 tasks are finished, no new tasks are scheduled immediately.  It 
> takes the last of the 4 tasks to finish before new 4 tasks would be 
> scheduled.  This happens on every node we've observed.
> This doesn't utilize available resources to the full extent allowed by the 
> --jobs N parameter.  In the field, on a cluster of 12 nodes with 4-5 TiB data 
> each, we've seen that the whole process was taking more than 7 days, instead 
> of estimated 1.5-2 days (provided there would be close to full N slots 
> utilization).
> Instead, new tasks should be scheduled as soon as there is a free compaction 
> slot.
> Additionally, starting from the biggest SSTables could further reduce the 
> total time required for the whole process to finish on any given node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14055) Index redistribution breaks SASI index

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-14055:
-

For sanity sake, I'm running the utests on [~jrwest]'s patch:

||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14055-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/14055-trunk]|
|[utests  
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14055-3.11]|[utests
  
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14055-trunk]|
||


> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x
>
> Attachments: CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch, CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14055) Index redistribution breaks SASI index

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-14055:
-

[~jrwest] patch does not compile on trunk. can you take a look?

{noformat}
build-test:
[javac] Compiling 587 source files to 
/orig/opt/dev/cassandra/build/test/classes
[javac] 
/orig/opt/dev/cassandra/test/unit/org/apache/cassandra/index/sasi/SASIIndexTest.java:946:
 error: cannot find symbol
[javac] int minIndexInterval = 
store.metadata.params.minIndexInterval;
[javac]  ^
[javac]   symbol:   variable params
[javac]   location: variable metadata of type TableMetadataRef
[javac] 
/orig/opt/dev/cassandra/test/unit/org/apache/cassandra/index/sasi/SASIIndexTest.java:955:
 error: cannot find symbol
[javac] store.metadata.minIndexInterval(minIndexInterval);
[javac]   ^
[javac]   symbol:   method minIndexInterval(int)
[javac]   location: variable metadata of type TableMetadataRef
[javac] 
/orig/opt/dev/cassandra/test/unit/org/apache/cassandra/index/sasi/SASIIndexTest.java:961:
 error: cannot find symbol
[javac] store.metadata.minIndexInterval(minIndexInterval);
[javac]   ^
[javac]   symbol:   method minIndexInterval(int)
[javac]   location: variable metadata of type TableMetadataRef
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 3 errors
{noformat}

> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x
>
> Attachments: CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch, CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-12588) Cannot find column durable_wrıtes

[Mustafa Kuscu (JIRA)]

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

Mustafa Kuscu commented on CASSANDRA-12588:
---

Some example runs from command line:

OK:    

{{     LANG= cassandra -f                }}

OK:    

{{     LANG=en_US.UTF-8 cassandra -f}}

But this FAILS:

{{     LANG=tr_TR.UTF-8 cassandra -f }}

I believe there are many Cassandra installations in Turkey who can serve 
Turkish content properly. Therefore although locale is instructed to JVM from 
the environment, the purpose of localization has no use from within Cassandra 
context. Is this correct?

Also, it is easy to get around this by ignoring LANG environment variable as 
can be seen in examples above.

As a permanent solution, I would like to propose, to force Locale.English to be 
used during startup. Something like the following

{{java.util.Locale.setDefault(java.util.Locale.English) }}

to be executed during startup. 

Is this possible?

 

> Cannot find column durable_wrıtes
> -
>
> Key: CASSANDRA-12588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12588
> Project: Cassandra
>  Issue Type: Bug
>Reporter: LLc.
>Priority: Major
>
> help please
> run :
> cassandra -f
> ERROR 17:00:16 Exception encountered during startup
> java.lang.AssertionError: Cannot find column durable_wrıtes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

cassandra-dtest git commit: Convert nose asserts to pytest (cdc_test, cqlsh_tools.py)

[spod]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 19a17fa90 -> 3d0d0f45f


Convert nose asserts to pytest (cdc_test, cqlsh_tools.py)


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

Branch: refs/heads/master
Commit: 3d0d0f45f56be3e4278a3bcfae763c052bf65dc7
Parents: 19a17fa
Author: Stefan Podkowinski 
Authored: Tue Feb 13 11:41:43 2018 +0100
Committer: Stefan Podkowinski 
Committed: Tue Feb 13 12:11:20 2018 +0100

--
 cdc_test.py| 77 +++--
 cqlsh_tests/cqlsh_tools.py |  5 ++-
 2 files changed, 37 insertions(+), 45 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/3d0d0f45/cdc_test.py
--
diff --git a/cdc_test.py b/cdc_test.py
index 4cbbb81..ebd4050 100644
--- a/cdc_test.py
+++ b/cdc_test.py
@@ -15,8 +15,6 @@ from cassandra import WriteFailure
 from cassandra.concurrent import (execute_concurrent,
   execute_concurrent_with_args)
 from ccmlib.node import Node
-from nose.tools import assert_equal, assert_less_equal, assert_not_equal, 
assert_less, assert_true, \
-assert_greater_equal, assert_not_in, assert_is_not_none, assert_raises
 
 from cqlsh_tests.cqlsh_tools import assert_resultset_contains
 from dtest import Tester, create_ks, logger
@@ -45,7 +43,7 @@ def _insert_rows(session, table_name, insert_stmt, values):
 logger.debug('{n} rows inserted into 
{table_name}'.format(n=len(data_loaded), table_name=table_name))
 # use assert_equal over assert_length_equal to avoid printing out
 # potentially large lists
-assert_equal(len(values), len(data_loaded))
+assert len(values) == len(data_loaded)
 return data_loaded
 
 
@@ -88,14 +86,12 @@ def _write_to_cdc_write_failure(session, insert_stmt):
 while not error_found:
 # We want to fail if inserting data takes too long. Locally this
 # takes about 10s, but let's be generous.
-assert_less_equal(
-(time.time() - start), 600,
-"It's taken more than 10 minutes to reach a WriteFailure trying "
-'to overrun the space designated for CDC commitlogs. This could '
-"be because data isn't being written quickly enough in this "
-'environment, or because C* is failing to reject writes when '
-'it should.'
-)
+assert ((time.time() - start) <= 600), (
+"It's taken more than 10 minutes to reach a WriteFailure 
trying "
+'to overrun the space designated for CDC commitlogs. This 
could '
+"be because data isn't being written quickly enough in this "
+'environment, or because C* is failing to reject writes when '
+'it should.')
 
 # If we haven't logged from here in the last 5s, do so.
 rate_limited_debug(
@@ -117,9 +113,8 @@ def _write_to_cdc_write_failure(session, insert_stmt):
 rows_loaded += len([br for br in batch_results if br[0]])
 # then, we make sure that the only failures are the expected
 # WriteFailure.
-assert_equal([],
- [result for (success, result) in batch_results
-  if not success and not isinstance(result, WriteFailure)])
+assert ([] == [result for (success, result) in batch_results
+   if not success and not isinstance(result, 
WriteFailure)])
 # Finally, if we find a WriteFailure, that means we've inserted all
 # the CDC data we can and so we flip error_found to exit the loop.
 if any(isinstance(result, WriteFailure) for (_, result) in 
batch_results):
@@ -276,8 +271,8 @@ class TestCDC(Tester):
 create_ks(session, ks_name, rf=1)
 
 if table_name is not None:
-assert_is_not_none(cdc_enabled_table, 'if creating a table in 
prepare, must specify whether or not CDC is enabled on it')
-assert_is_not_none(column_spec, 'if creating a table in prepare, 
must specify its schema')
+assert cdc_enabled_table is not None, 'if creating a table in 
prepare, must specify whether or not CDC is enabled on it'
+assert column_spec is not None, 'if creating a table in prepare, 
must specify its schema'
 options = {}
 if gc_grace_seconds is not None:
 options['gc_grace_seconds'] = gc_grace_seconds
@@ -320,7 +315,7 @@ class TestCDC(Tester):
 execute_concurrent_with_args(session, 

[jira] [Resolved] (CASSANDRA-13546) Getting error while adding a node in existing cluster

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski resolved CASSANDRA-13546.

Resolution: Cannot Reproduce

> Getting error while adding a node in existing cluster
> -
>
> Key: CASSANDRA-13546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13546
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Unix
>Reporter: Sonu Gupta
>Priority: Major
> Fix For: 2.1.x
>
>
> Getting error after adding a node in existing cluster, error are coming after 
> 1 hour after started service on seed node and due to this load got increased 
> vastly on seed node not on new node.
> Below errors from system.log on seed node:
> {code}
> ERROR [NonPeriodicTasks:1] 2017-05-18 10:03:01,819 CassandraDaemon.java:153 - 
> Exception in thread Thread[NonPeriodicTasks:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.io.util.Memory.free(Memory.java:300) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.utils.obs.OffHeapBitSet.close(OffHeapBitSet.java:143) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at org.apache.cassandra.utils.BloomFilter.close(BloomFilter.java:116) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:645) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown 
> Source) ~[na:1.7.0_71]
> at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_71]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown
>  Source) ~[na:1.7.0_71]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source) ~[na:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [na:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [na:1.7.0_71]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_71]
> INFO  [CompactionExecutor:162] 2017-05-18 10:03:01,820 
> ColumnFamilyStore.java:840 - Enqueuing flush of compactions_in_progress: 164 
> (0%) on-heap, 0 (0%) off-heap
> INFO  [MemtableFlushWriter:152] 2017-05-18 10:03:01,821 Memtable.java:325 - 
> Writing Memtable-compactions_in_progress@731506998(0 serialized bytes, 1 ops, 
> 0%/0% of on/off-heap limit)
> INFO  [MemtableFlushWriter:152] 2017-05-18 10:03:01,825 Memtable.java:364 - 
> Completed flushing 
> /var/lib/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-ka-52434-Data.db
>  (42 bytes) for commitlog position ReplayPosition(segmentId=1495106933696, 
> position=9156004)
> ERROR [CompactionExecutor:162] 2017-05-18 10:03:01,829 
> CassandraDaemon.java:153 -
>  Exception in thread Thread[CompactionExecutor:162,1,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.io.util.Memory.free(Memory.java:300) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.utils.obs.OffHeapBitSet.close(OffHeapBitSet.java:143) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at org.apache.cassandra.utils.BloomFilter.close(BloomFilter.java:116) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.abort(SSTableWriter.java:345) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.abort(SSTableRewriter.java:198)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:204)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:75)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:232)
>  ~[apache-cassandra-2.1.2.jar:2.1.2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown 
> Source) ~[na:1.7.0_71]
> at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_71]
>

[jira] [Updated] (CASSANDRA-12793) invalid jvm type and architecture [cassandra-env.sh]

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12793:
---
Attachment: 12793.patch

> invalid jvm type and architecture [cassandra-env.sh]
> 
>
> Key: CASSANDRA-12793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12793
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: ubuntu 16.04, openjdk 1.8.0_91
>Reporter: Ali Ebrahiminejad
>Priority: Minor
> Fix For: 3.11.x
>
> Attachments: 12793.patch
>
>
> In cassandra-env.sh the part that determines the type of JVM we'll be running 
> on doesn't provide the right answer for openjdk 1.8.0_91.
> value of java_ver_output is "openjdk version "1.8.0_91" OpenJDK Runtime 
> Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14) OpenJDK 64-Bit 
> Server VM (build 25.91-b14, mixed mode)", yet the command looks for "java 
> version" (jvm=`echo "$java_ver_output" | grep -A 1 'java version' ...) which 
> does not exist.
> I guess it should be replaced with jvm=`echo "$java_ver_output" | grep -A 1 
> '[openjdk|java] version' | awk 'NR==2 {print $1}'`



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-12793) invalid jvm type and architecture [cassandra-env.sh]

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski reassigned CASSANDRA-12793:
--

Assignee: Stefan Podkowinski

> invalid jvm type and architecture [cassandra-env.sh]
> 
>
> Key: CASSANDRA-12793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12793
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: ubuntu 16.04, openjdk 1.8.0_91
>Reporter: Ali Ebrahiminejad
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 3.11.x
>
> Attachments: 12793.patch
>
>
> In cassandra-env.sh the part that determines the type of JVM we'll be running 
> on doesn't provide the right answer for openjdk 1.8.0_91.
> value of java_ver_output is "openjdk version "1.8.0_91" OpenJDK Runtime 
> Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14) OpenJDK 64-Bit 
> Server VM (build 25.91-b14, mixed mode)", yet the command looks for "java 
> version" (jvm=`echo "$java_ver_output" | grep -A 1 'java version' ...) which 
> does not exist.
> I guess it should be replaced with jvm=`echo "$java_ver_output" | grep -A 1 
> '[openjdk|java] version' | awk 'NR==2 {print $1}'`



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (CASSANDRA-13330) /var/run/cassandra directory not created on Centos7

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski resolved CASSANDRA-13330.

   Resolution: Won't Fix
Fix Version/s: (was: 3.11.x)

Affected version is no longer supported, neither are datastax packages. Please 
open a new ticket if this issue can be reproduced in a recent Apache release.

> /var/run/cassandra directory not created on Centos7
> ---
>
> Key: CASSANDRA-13330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13330
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: CentOS Linux release 7.3.1611 (Core) (x86_64)
> datastax-ddc.noarch 3.9.0-1  
> datastax-ddc-tools.noarch   3.9.0-1   
> java-1.8.0-openjdk.x86_64   1:1.8.0.121-0.b13.el7_3  
> java-1.8.0-openjdk-headless.x86_64  1:1.8.0.121-0.b13.el7_3 
>Reporter: Tobi
>Priority: Minor
>
> After updating cassandra from 3.4 to 3.9 via the datastax repo the startup 
> script /etc/init.d/cassandra was unable to stop cassandra. After checking the 
> startscript we found that it's tried to read pid file from 
> /var/run/cassandra/cassandra.pid
> But as this path does not exist, the cassandra process could not be stopped. 
> As a fix we created /usr/lib/tmpfiles.d/cassandra.conf with this content
> d /var/run/cassandra  0750  cassandra cassandra   -   
> -
> After that the directory was created on boot and the pid file could we 
> written in it



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14231) After ddl cluster.getMetadata().checkSchemaAgreement() returns true but schema is not in agreement

[George Shuklin (JIRA)]

George Shuklin created CASSANDRA-14231:
--

 Summary: After ddl cluster.getMetadata().checkSchemaAgreement() 
returns true but schema is not in agreement
 Key: CASSANDRA-14231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14231
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: George Shuklin
 Fix For: 3.10


We run a set of ddl statements and after each of them wait until schema come to 
agreement. However periodically after Cluster says that schema is in agreement 
and we run next DDL statement, it fails as previous DDL did not work properly. 

The most typical scenario when this problem happens almost always: first DDL 
drops a table, and next DDL creates it (and cassandra says that this table 
already exists).

 

This is our code to wait:

private void waitForSchemaAgreement()
 {
while (!icluster.getMetadata().checkSchemaAgreement()) {
try {
 Thread.sleep(waitTime*1000);
 } catch (Exception e){

// ignore  } } }

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-12793) invalid jvm type and architecture [cassandra-env.sh]

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-12793:
---
Status: Patch Available  (was: Open)

Thanks for reporting and sorry it took so long to respond. 

The issue is easy to reproduce and the suggested change does fix the issue. 
Eventually the broken OpenJDK detection will currently prevent the 
"-XX:+UseCondCardMark" flag from being set automatically.

OpenJDK unpatched:

{noformat}
+ java -version
+ java_ver_output=openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ grep [openjdk|java] version
+ cut -d- -f1
+ echo openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ awk -F" NR==1 {print $2}
+ jvmver=1.8.0_151
+ JVM_VERSION=1.8.0
+ JVM_PATCH_VERSION=151
+ [ 1.8.0 < 1.8 ]
+ [ 1.8.0 < 1.8 ]
+ echo openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ + awk NR==2 {print $1}
grep -A 1 java version
+ jvm=
+ JVM_VENDOR=other
+ JVM_ARCH=unknown
{noformat}


Oracle JDK unpatched:

{noformat}
+ java -version
+ java_ver_output=java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ echo java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ grep [openjdk|java] version
+ cut -d- -f1
+ awk -F" NR==1 {print $2}
+ jvmver=1.8.0_161
+ JVM_VERSION=1.8.0
+ JVM_PATCH_VERSION=161
+ [ 1.8.0 < 1.8 ]
+ [ 1.8.0 < 1.8 ]
+ echo java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ + awkgrep NR==2 {print $1}
 -A 1 java version
+ jvm=Java(TM)
+ JVM_VENDOR=Oracle
+ echo java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ awk NR==3 {print $3}
+ JVM_ARCH=64-Bit
{noformat}

OpenJDK patched:

{noformat}
+ java -version
+ java_ver_output=openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ echo openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ grep [openjdk|java] version
+ cut -d- -f1
+ awk -F" NR==1 {print $2}
+ jvmver=1.8.0_151
+ JVM_VERSION=1.8.0
+ JVM_PATCH_VERSION=151
+ [ 1.8.0 < 1.8 ]
+ [ 1.8.0 < 1.8 ]
+ grep -A 1 [openjdk|java] version
+ awk NR==2 {print $1}
+ echo openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ jvm=OpenJDK
+ JVM_VENDOR=OpenJDK
+ + awk NR==3 {print $2}
echo openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
+ JVM_ARCH=64-Bit
{noformat}

Oracle patched:

{noformat}
+ java -version
+ java_ver_output=java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ echo java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ grep [openjdk|java] version+ cut -d- -f1
+ awk -F" NR==1 {print $2}
+ jvmver=1.8.0_161
+ JVM_VERSION=1.8.0
+ JVM_PATCH_VERSION=161
+ [ 1.8.0 < 1.8 ]
+ [ 1.8.0 < 1.8 ]
+ echo java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ grep -A 1 [openjdk|java] version
+ awk NR==2 {print $1}
+ jvm=Java(TM)
+ JVM_VENDOR=Oracle
+ echo+ awk NR==3 {print $3}
 java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
+ JVM_ARCH=64-Bit
{noformat}


> invalid jvm type and architecture [cassandra-env.sh]
> 
>
> Key: CASSANDRA-12793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12793
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: ubuntu 16.04, openjdk 1.8.0_91
>Reporter: Ali Ebrahiminejad
>Priority: Minor
> Fix For: 3.11.x
>
> Attachments: 12793.patch
>
>
> In cassandra-env.sh the part that determines the type of JVM we'll be running 
> on doesn't provide the right answer for 

[jira] [Commented] (CASSANDRA-13259) Use platform specific X.509 default algorithm

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13259:


Lets then remove it from the yaml but keep it in EncryptionOptions. 

I'd suggest to commit this to trunk only, as this is not a bug fix and the 
value can be explicitly set in the yaml, in the hypothetical case SunX509 is 
getting pulled from future JVM releases.

> Use platform specific X.509 default algorithm
> -
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE 
> default instead. This implementation will currently not work on less popular 
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13259) Use platform specific X.509 default algorithm

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13259:
-

On the whole, +1. {{SunX509}} still appears in the yaml, under 
{{server_encryption_options}} and {{client_encryption_options}}. I'm not sure 
what the best thing to do here is. We could:

- remove the {{algorithm}} property altogether from the yaml - yet leave it in 
the {{EncryptionOptions}} in case somebody actually has a custom algo 
implmentation (highly doubtful, but it costs us nothing to keep it)
- remove {{SunX509}} as the value of the property, although this might confuse 
an operator to see an empty prop value and they may try to shove something in 
the attempt to make it happy (even though they don't need it)
- replace {{SunX509}} with whatever the new default algo name is (I couldn't 
find it with a naive, 30 second search), although this may, at some distant 
future date, get us into the same situation we are in now.

I'm mildly in favor of the first option. wdyt?

> Use platform specific X.509 default algorithm
> -
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE 
> default instead. This implementation will currently not work on less popular 
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-14225:


Testing in CircleCI 
https://circleci.com/gh/aweisberg/cassandra/tree/cassandra-14225
https://github.com/apache/cassandra/compare/trunk...aweisberg:cassandra-14225?expand=1

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14226) Better document in code InetAddressAndPort usage post 7544

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14226:
---
Reviewer: Jon Haddad

> Better document in code InetAddressAndPort usage post 7544
> --
>
> Key: CASSANDRA-14226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14226
> Project: Cassandra
>  Issue Type: Task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> There seems to be some confusion as to what some of the various methods and 
> configuration options do and how you should use them to correctly identify 
> nodes and compare them. Try and add more comments to explain what is going on.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Labels:   (was: lhf)

> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> See comment here: 
> https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14055) Index redistribution breaks SASI index

[Ludovic Boutros (JIRA)]

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

Ludovic Boutros commented on CASSANDRA-14055:
-

Hi [~jrwest],

thx for your patch. The main difference between the two patches is that you do 
not release old {{SSTableIndex}} objects at all.

This way you do not remove the index file. On the other hand, don't you think 
you will have an issue in the reference count ? I'm not sure but in my 
understanding, the global count will never go down to zero. But perhaps am I 
wrong.




 

 

> Index redistribution breaks SASI index
> --
>
> Key: CASSANDRA-14055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14055
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Ludovic Boutros
>Assignee: Ludovic Boutros
>Priority: Major
>  Labels: patch
> Fix For: 3.11.x, 4.x
>
> Attachments: CASSANDRA-14055-jrwest.patch, CASSANDRA-14055.patch, 
> CASSANDRA-14055.patch, CASSANDRA-14055.patch
>
>
> During index redistribution process, a new view is created.
> During this creation, old indexes should be released.
> But, new indexes are "attached" to the same SSTable as the old indexes.
> This leads to the deletion of the last SASI index file and breaks the index.
> The issue is in this function : 
> [https://github.com/apache/cassandra/blob/9ee44db49b13d4b4c91c9d6332ce06a6e2abf944/src/java/org/apache/cassandra/index/sasi/conf/view/View.java#L62]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Description: 
Includes write ops and latencies at coordinator per column family.

Relevant discussion thread in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Useful in a multi tenant cluster, where different column families are owned 
by different teams
 * Ability to identify specific column family that coordinator writes are slow 
to

  was:See comment here: 
https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875


> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
>
> Includes write ops and latencies at coordinator per column family.
> Relevant discussion thread in dev mailing list - 
> [https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]
> Below are a few advantages of having such metric
>  * Useful in a multi tenant cluster, where different column families are 
> owned by different teams
>  * Ability to identify specific column family that coordinator writes are 
> slow to



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-13259) Use platform specific X.509 default algorithm

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13259:

Status: Ready to Commit  (was: Awaiting Feedback)

> Use platform specific X.509 default algorithm
> -
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE 
> default instead. This implementation will currently not work on less popular 
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-14183:


As discussed on the dev@ list and IRC, I have experienced third-party 
application failure upon updating to logback-1.2.3, so I am not keen on 
updating the jar in stable branches without due diligence on test updates and 
user notification.

I'm fine with committing an update to trunk.

Dropping in a new jar is not all that's needed for a complete fix, since we 
break unit tests. I attached a git patch on trunk that was created for the 
purpose of fixing log rotation, but it does not build properly, at the moment. 
It has the cql3 test changes needed, as well as some notes on obsoleted api 
changes in logback since 1.1.3.

I hope it helps.

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
> Attachments: 
> 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14225:
---
Status: Patch Available  (was: Open)

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg reassigned CASSANDRA-14225:
--

Assignee: Dave Brosius  (was: Ariel Weisberg)
Reviewer: Ariel Weisberg

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14226) Better document in code InetAddressAndPort usage post 7544, incorporate port into UUIDGen node

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14226:
---
Description: 
There seems to be some confusion as to what some of the various methods and 
configuration options do and how you should use them to correctly identify 
nodes and compare them. Try and add more comments to explain what is going on.

Also make UUIGen node incorporate the port and not just address to be 
consistent with what we consider and instance to be.

  was:There seems to be some confusion as to what some of the various methods 
and configuration options do and how you should use them to correctly identify 
nodes and compare them. Try and add more comments to explain what is going on.


> Better document in code InetAddressAndPort usage post 7544, incorporate port 
> into UUIDGen node
> --
>
> Key: CASSANDRA-14226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14226
> Project: Cassandra
>  Issue Type: Task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> There seems to be some confusion as to what some of the various methods and 
> configuration options do and how you should use them to correctly identify 
> nodes and compare them. Try and add more comments to explain what is going on.
> Also make UUIGen node incorporate the port and not just address to be 
> consistent with what we consider and instance to be.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Reviewer:   (was: Marcus Eriksson)

> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> See comment here: 
> https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

Sumanth Pasupuleti created CASSANDRA-14232:
--

 Summary: Add metric for coordinator writes per column family
 Key: CASSANDRA-14232
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
 Project: Cassandra
  Issue Type: Bug
Reporter: Sumanth Pasupuleti
Assignee: Sumanth Pasupuleti
 Fix For: 3.0.16, 3.11.2, 4.0


See comment here: 
https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Issue Type: Improvement  (was: Bug)

> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> See comment here: 
> https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14183:
---
Reviewer: Ariel Weisberg

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13259) Use platform specific X.509 default algorithm

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13259:
-

bq. I'd suggest to commit this to trunk only

Hmm, I think you are right here - not only for the yaml change, but silently 
swapping part of the SSL implementation during a minor is not cool (without a 
legitimately good reason).

So, +1 to the patch and removing the yaml entry for trunk only.

> Use platform specific X.509 default algorithm
> -
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE 
> default instead. This implementation will currently not work on less popular 
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14226) Better document in code InetAddressAndPort usage post 7544, incorporate port into UUIDGen node

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14226:
---
Summary: Better document in code InetAddressAndPort usage post 7544, 
incorporate port into UUIDGen node  (was: Better document in code 
InetAddressAndPort usage post 7544)

> Better document in code InetAddressAndPort usage post 7544, incorporate port 
> into UUIDGen node
> --
>
> Key: CASSANDRA-14226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14226
> Project: Cassandra
>  Issue Type: Task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> There seems to be some confusion as to what some of the various methods and 
> configuration options do and how you should use them to correctly identify 
> nodes and compare them. Try and add more comments to explain what is going on.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-14183:
---
Attachment: 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
> Attachments: 
> 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Fix Version/s: (was: 3.11.2)
   (was: 3.0.16)
   (was: 4.0)

> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
>
> See comment here: 
> https://issues.apache.org/jira/browse/CASSANDRA-13922?focusedCommentId=16189875=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16189875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Description: 
Includes write ops and latencies at coordinator per column family.

Relevant discussion in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Ability to identify specific column family that coordinator writes are slow 
to
 * Especially useful in a multi-tenant cluster, where different column families 
are owned by different teams

  was:
Includes write ops and latencies at coordinator per column family.

Relevant discussion in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Ability to identify specific column family that coordinator writes are slow 
to
 * Useful in a multi-tenant cluster, where different column families are owned 
by different teams


> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
>
> Includes write ops and latencies at coordinator per column family.
> Relevant discussion in dev mailing list - 
> [https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]
> Below are a few advantages of having such metric
>  * Ability to identify specific column family that coordinator writes are 
> slow to
>  * Especially useful in a multi-tenant cluster, where different column 
> families are owned by different teams



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Description: 
Includes write ops and latencies at coordinator per column family.

Relevant discussion in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Ability to identify specific column family that coordinator writes are slow 
to
 * Also useful in a multi-tenant cluster, where different column families are 
owned by different teams

  was:
Includes write ops and latencies at coordinator per column family.

Relevant discussion in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Ability to identify specific column family that coordinator writes are slow 
to
 * Especially useful in a multi-tenant cluster, where different column families 
are owned by different teams


> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
>
> Includes write ops and latencies at coordinator per column family.
> Relevant discussion in dev mailing list - 
> [https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]
> Below are a few advantages of having such metric
>  * Ability to identify specific column family that coordinator writes are 
> slow to
>  * Also useful in a multi-tenant cluster, where different column families are 
> owned by different teams



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14232) Add metric for coordinator writes per column family

[Sumanth Pasupuleti (JIRA)]

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

Sumanth Pasupuleti updated CASSANDRA-14232:
---
Description: 
Includes write ops and latencies at coordinator per column family.

Relevant discussion in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Ability to identify specific column family that coordinator writes are slow 
to
 * Useful in a multi-tenant cluster, where different column families are owned 
by different teams

  was:
Includes write ops and latencies at coordinator per column family.

Relevant discussion thread in dev mailing list - 
[https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]

Below are a few advantages of having such metric
 * Useful in a multi tenant cluster, where different column families are owned 
by different teams
 * Ability to identify specific column family that coordinator writes are slow 
to


> Add metric for coordinator writes per column family
> ---
>
> Key: CASSANDRA-14232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14232
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Major
>
> Includes write ops and latencies at coordinator per column family.
> Relevant discussion in dev mailing list - 
> [https://lists.apache.org/thread.html/f68f694b13b670a1fa28fa75620304603fc89e94ec515933199f4c37@%3Cdev.cassandra.apache.org%3E]
> Below are a few advantages of having such metric
>  * Ability to identify specific column family that coordinator writes are 
> slow to
>  * Useful in a multi-tenant cluster, where different column families are 
> owned by different teams



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-14183:
---
Attachment: (was: 
0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch)

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
> Attachments: 
> 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-14183:


Updated patch for trunk that includes the binary bits this time and builds fine 
:)

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
> Attachments: 
> 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14183) CVE-2017-5929 Security vulnerability

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-14183:
---
Attachment: 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch

> CVE-2017-5929 Security vulnerability
> 
>
> Key: CASSANDRA-14183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Thiago Veronezi
>Assignee: Thiago Veronezi
>Priority: Major
>  Labels: patch, security
> Fix For: 3.11.x
>
> Attachments: 
> 0001-Update-to-logback-1.2.3-and-redefine-default-rotatio.patch
>
>
> Cassandra 3.11.1 is patched with logback 1.1.3, which contains the security 
> vulnerability described here. 
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5929]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14226) Better document in code InetAddressAndPort usage post 7544, incorporate port into UUIDGen node

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14226:
---
Status: Ready to Commit  (was: Patch Available)

> Better document in code InetAddressAndPort usage post 7544, incorporate port 
> into UUIDGen node
> --
>
> Key: CASSANDRA-14226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14226
> Project: Cassandra
>  Issue Type: Task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> There seems to be some confusion as to what some of the various methods and 
> configuration options do and how you should use them to correctly identify 
> nodes and compare them. Try and add more comments to explain what is going on.
> Also make UUIGen node incorporate the port and not just address to be 
> consistent with what we consider and instance to be.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14226) Better document in code InetAddressAndPort usage post 7544, incorporate port into UUIDGen node

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14226:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed as 
[518ddbf9d21491d341a3d7e2f2a2e65409595e07|https://github.com/apache/cassandra/commit/518ddbf9d21491d341a3d7e2f2a2e65409595e07]
 

> Better document in code InetAddressAndPort usage post 7544, incorporate port 
> into UUIDGen node
> --
>
> Key: CASSANDRA-14226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14226
> Project: Cassandra
>  Issue Type: Task
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> There seems to be some confusion as to what some of the various methods and 
> configuration options do and how you should use them to correctly identify 
> nodes and compare them. Try and add more comments to explain what is going on.
> Also make UUIGen node incorporate the port and not just address to be 
> consistent with what we consider and instance to be.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

Samuel Roberts created CASSANDRA-14233:
--

 Summary: nodetool tablestats/cfstats output has inconsistent 
formatting for latency
 Key: CASSANDRA-14233
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
 Project: Cassandra
  Issue Type: Bug
Reporter: Samuel Roberts


Latencies are reported at keyspace level with `ms.` and at table level with 
`ms`.

There should be no trailing "." as it is not a sentence and "." is not part of 
the abbreviation.

This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Reproduced In: 3.11.1  (was: 3.0.11)

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing "." as it is not a sentence and "." is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

cassandra git commit: Better document in code InetAddressAndPort usage post 7544

[aweisberg]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 1188fcb08 -> 518ddbf9d


Better document in code InetAddressAndPort usage post 7544

Patch by Ariel Weisberg; Reviewed by Jon Haddad for CASSANDRA-14226


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

Branch: refs/heads/trunk
Commit: 518ddbf9d21491d341a3d7e2f2a2e65409595e07
Parents: 1188fcb
Author: Ariel Weisberg 
Authored: Fri Feb 9 17:38:52 2018 -0500
Committer: Ariel Weisberg 
Committed: Tue Feb 13 17:20:11 2018 -0500

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/config/Config.java |  7 +++
 .../cassandra/config/DatabaseDescriptor.java| 17 +-
 .../org/apache/cassandra/utils/FBUtilities.java | 43 ---
 .../org/apache/cassandra/utils/UUIDGen.java | 58 ++--
 5 files changed, 101 insertions(+), 25 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/518ddbf9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c8eb6f0..d7f1f4e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Better document in code InetAddressAndPort usage post 7544, incorporate 
port into UUIDGen node (CASSANDRA-14226)
  * Fix sstablemetadata date string for minLocalDeletionTime (CASSANDRA-14132)
  * Make it possible to change neverPurgeTombstones during runtime 
(CASSANDRA-14214)
  * Remove GossipDigestSynVerbHandler#doSort() (CASSANDRA-14174)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/518ddbf9/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java 
b/src/java/org/apache/cassandra/config/Config.java
index 1db8217..875751b 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -128,6 +128,13 @@ public class Config
 public boolean listen_on_broadcast_address = false;
 public String internode_authenticator;
 
+/*
+ * RPC address and interface refer to the address/interface used for the 
native protocol used to communicate with
+ * clients. It's still called RPC in some places even though Thrift RPC is 
gone. If you see references to native
+ * address or native port it's derived from the RPC address configuration.
+ *
+ * native_transport_port is the port that is paired with RPC address to 
bind on.
+ */
 public String rpc_address;
 public String rpc_interface;
 public boolean rpc_interface_prefer_ipv6 = false;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/518ddbf9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 0714245..ccb0a30 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -1725,6 +1725,12 @@ public class DatabaseDescriptor
 broadcastAddress = broadcastAdd;
 }
 
+/**
+ * This is the address used to bind for the native protocol to communicate 
with clients. Most usages in the code
+ * refer to it as native address although some places still call it RPC 
address. It's not thrift RPC anymore
+ * so native is more appropriate. The address alone is not enough to 
uniquely identify this instance because
+ * multiple instances might use the same interface with different ports.
+ */
 public static InetAddress getRpcAddress()
 {
 return rpcAddress;
@@ -1736,7 +1742,12 @@ public class DatabaseDescriptor
 }
 
 /**
- * May be null, please use {@link FBUtilities#getBroadcastRpcAddress()} 
instead.
+ * This is the address used to reach this instance for the native protocol 
to communicate with clients. Most usages in the code
+ * refer to it as native address although some places still call it RPC 
address. It's not thrift RPC anymore
+ * so native is more appropriate. The address alone is not enough to 
uniquely identify this instance because
+ * multiple instances might use the same interface with different ports.
+ *
+ * May be null, please use {@link 
FBUtilities#getBroadcastNativeAddressAndPort()} instead.
  */
 public static InetAddress getBroadcastRpcAddress()
 {
@@ -1763,6 +1774,10 @@ public class DatabaseDescriptor
   

[jira] [Commented] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-14234:
-

using {{git bisect}}, it looks like the commit that broke the unit test is 
{{9d649d69a56a91fcb06a3582b22606f0fe361f49}}, introduced in CASSANDRA-8527. 

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-14234:
-

patch looks clean/compiles/test succeeds on 3.11, but trunk fails to apply 
cleanly. [~KurtG] can you take a look at that, as well?

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-14234:
-

3.11 utest run [looks 
good|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14234-3.11].

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14200:
---

+1 change looks good to me

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Chris Lohfink (JIRA)]

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

Chris Lohfink updated CASSANDRA-14200:
--
Status: Ready to Commit  (was: Patch Available)

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Simon Zhou (JIRA)]

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

Simon Zhou commented on CASSANDRA-14200:


Thanks [~cnlwsu]! I'll provide patches for 3.11 and 4.0 shortly.

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14200:
---

may wanna just start with trunk and let a committer come around and make call 
for how far back versions should go

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14199) exception when dumping sstable with frozen collection of UUID

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14199:
---

this is fixed on trunk it looks like

{code}
[
  {
"partition" : {
  "key" : [ "id" ],
  "position" : 0
},
"rows" : [
  {
"type" : "row",
"position" : 186,
"liveness_info" : { "tstamp" : "2018-02-14T03:57:41.791250Z" },
"cells" : [
  { "name" : "c2", "value" : ["6947e8c0-02fa-11e8-87e1-fb0d0e20b5c4"] },
  { "name" : "c4", "value" : ["over", "view"] },
  { "name" : "c6", "value" : {"driver": "java", "note": "new"} },
  { "name" : "c1", "deletion_info" : { "marked_deleted" : 
"2018-02-14T03:57:41.791249Z", "local_delete_time" : "2018-02-14T03:57:41Z" } },
  { "name" : "c1", "path" : [ "34991370-113b-11e8-9d5e-515f8b1c000b" ], 
"value" : "6947e8c0-02fa-11e8-87e1-fb0d0e20b5c4" },
  { "name" : "c3", "deletion_info" : { "marked_deleted" : 
"2018-02-14T03:57:41.791249Z", "local_delete_time" : "2018-02-14T03:57:41Z" } },
  { "name" : "c3", "path" : [ "set" ], "value" : "" },
  { "name" : "c3", "path" : [ "user" ], "value" : "" },
  { "name" : "c5", "deletion_info" : { "marked_deleted" : 
"2018-02-14T03:57:41.791249Z", "local_delete_time" : "2018-02-14T03:57:41Z" } },
  { "name" : "c5", "path" : [ "good" ], "value" : "hello" },
  { "name" : "c5", "path" : [ "root" ], "value" : "text" }
]
  }
]
  }
]
{code}

> exception when dumping sstable with frozen collection of UUID
> -
>
> Key: CASSANDRA-14199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14199
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> When dumping (sstabledump) sstable with frozen collection of UUID, there is 
> exception like this:
> {code:java}
> Exception in thread "main" org.apache.cassandra.serializers.MarshalException: 
> UUID should be 16 or 0 bytes (24)
> at 
> org.apache.cassandra.serializers.UUIDSerializer.validate(UUIDSerializer.java:43)
> at 
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:128)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:440)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:374)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:278)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:213)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at 
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:102)
> at 
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
>  
> *Steps to reproduce:*
> {code:java}
> cqlsh> create TABLE stresscql.sstabledump_test(userid text PRIMARY KEY, c1 
> list, c2 frozen, c3 set, c4 frozen, c5 
> map, c6 frozen>);
> cqlsh> insert INTO stresscql.sstabledump_test (userid, c1, c2, c3, c4, c5, 
> c6) VALUES ( 'id', [6947e8c0-02fa-11e8-87e1-fb0d0e20b5c4], 
> [6947e8c0-02fa-11e8-87e1-fb0d0e20b5c4], {'set', 'user'}, {'view', 'over'}, 
> {'good': 'hello', 'root': 'text'}, {'driver': 'java', 'note': 'new'});{code}
>  
> *Root cause:*
> Frozen collection is treated as simple column and it's the client's 
> responsibility to parse the data from ByteBuffer. We have this logic in 
> different drivers but sstabledump doesn't have the logic in place. It just 
> treat the whole collection as a single UUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: 

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14200:
---

how do you reproduce this?

{code}
CREATE TABLE c14200 (key text PRIMARY KEY , value text, ts timestamp);
INSERT INTO c14200 (key, value) VALUES ('key','value');
INSERT INTO c14200 (key, value, ts) VALUES ('key','value', 1);
{code}

had no issue
works fine

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14200:
---

looking at trunk, I am not sure this patch is necessary any longer.

> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Status: Awaiting Feedback  (was: Open)

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing "." as it is not a sentence and "." is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts commented on CASSANDRA-14233:


Very simple to fix:

[https://github.com/sproberts92/cassandra/commit/05ccb4851bf2ab1f35237ec901e1426a9bda]

but I am confused about which branch to commit to - docs state start with the 
oldest branch? As the file has been moved around a lot and names changed I'm 
not sure if this will propagate to 3.x cleanly.

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing "." as it is not a sentence and "." is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts edited comment on CASSANDRA-14233 at 2/13/18 10:58 PM:
--

Very simple to fix:

[https://github.com/sproberts92/cassandra/commit/05ccb4851bf2ab1f35237ec901e1426a9bda]

but I am confused about which branch to commit to - docs state start with the 
oldest branch? As the file has been moved around a lot and names changed so I'm 
not sure if this will propagate to 3.x cleanly.


was (Author: sproberts92):
Very simple to fix:

[https://github.com/sproberts92/cassandra/commit/05ccb4851bf2ab1f35237ec901e1426a9bda]

but I am confused about which branch to commit to - docs state start with the 
oldest branch? As the file has been moved around a lot and names changed I'm 
not sure if this will propagate to 3.x cleanly.

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing "." as it is not a sentence and "." is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts edited comment on CASSANDRA-14233 at 2/13/18 10:58 PM:
--

Very simple to fix:

[https://github.com/sproberts92/cassandra/commit/05ccb4851bf2ab1f35237ec901e1426a9bda]

but I am confused about which branch to commit to - docs state start with the 
oldest branch? As the file has been moved around a lot and names changed, I'm 
not sure if this will propagate to 3.x cleanly.


was (Author: sproberts92):
Very simple to fix:

[https://github.com/sproberts92/cassandra/commit/05ccb4851bf2ab1f35237ec901e1426a9bda]

but I am confused about which branch to commit to - docs state start with the 
oldest branch? As the file has been moved around a lot and names changed so I'm 
not sure if this will propagate to 3.x cleanly.

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing "." as it is not a sentence and "." is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

cassandra git commit: Fix comparison of address and port for repair and messages

[aweisberg]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 518ddbf9d -> 834f2a6ec


Fix comparison of address and port for repair and messages

Patch by Dave Brosius; Reviewed by Ariel Weisberg for CASSANDRA-14225


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

Branch: refs/heads/trunk
Commit: 834f2a6ecdb8974839762bf4e9c5fed32163f9c8
Parents: 518ddbf
Author: Dave Brosius 
Authored: Tue Feb 13 12:30:59 2018 -0500
Committer: Ariel Weisberg 
Committed: Tue Feb 13 17:46:44 2018 -0500

--
 src/java/org/apache/cassandra/net/MessageIn.java | 4 +++-
 src/java/org/apache/cassandra/repair/RepairRunnable.java | 9 +++--
 2 files changed, 10 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/834f2a6e/src/java/org/apache/cassandra/net/MessageIn.java
--
diff --git a/src/java/org/apache/cassandra/net/MessageIn.java 
b/src/java/org/apache/cassandra/net/MessageIn.java
index ab77f33..1cd7547 100644
--- a/src/java/org/apache/cassandra/net/MessageIn.java
+++ b/src/java/org/apache/cassandra/net/MessageIn.java
@@ -32,6 +32,8 @@ import org.apache.cassandra.io.util.DataInputBuffer;
 import org.apache.cassandra.io.util.DataInputPlus;
 import org.apache.cassandra.locator.InetAddressAndPort;
 import org.apache.cassandra.net.MessagingService.Verb;
+import org.apache.cassandra.utils.FBUtilities;
+
 /**
  * The receiving node's view of a {@link MessageOut}. See documentation on 
{@link MessageOut} for details on the
  * serialization format.
@@ -180,7 +182,7 @@ public class MessageIn
  */
 public boolean isCrossNode()
 {
-return !from.address.equals(DatabaseDescriptor.getBroadcastAddress());
+return !from.equals(FBUtilities.getBroadcastAddressAndPort());
 }
 
 public Stage getMessageType()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/834f2a6e/src/java/org/apache/cassandra/repair/RepairRunnable.java
--
diff --git a/src/java/org/apache/cassandra/repair/RepairRunnable.java 
b/src/java/org/apache/cassandra/repair/RepairRunnable.java
index ebe736d..89177ee 100644
--- a/src/java/org/apache/cassandra/repair/RepairRunnable.java
+++ b/src/java/org/apache/cassandra/repair/RepairRunnable.java
@@ -46,6 +46,7 @@ import org.slf4j.LoggerFactory;
 import com.codahale.metrics.Timer;
 import org.apache.cassandra.concurrent.JMXConfigurableThreadPoolExecutor;
 import org.apache.cassandra.concurrent.NamedThreadFactory;
+import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.gms.FailureDetector;
 import org.apache.cassandra.repair.consistent.SyncStatSummary;
 import org.apache.cassandra.schema.SchemaConstants;
@@ -704,7 +705,7 @@ public class RepairRunnable extends WrappedRunnable 
implements ProgressEventNoti
 if (state == null)
 throw new Exception("no tracestate");
 
-String format = "select event_id, source, activity from %s.%s 
where session_id = ? and event_id > ? and event_id < ?;";
+String format = "select event_id, source, source_port, 
activity from %s.%s where session_id = ? and event_id > ? and event_id < ?;";
 String query = String.format(format, 
SchemaConstants.TRACE_KEYSPACE_NAME, TraceKeyspace.EVENTS);
 SelectStatement statement = (SelectStatement) 
QueryProcessor.parseStatement(query).prepare().statement;
 
@@ -745,7 +746,11 @@ public class RepairRunnable extends WrappedRunnable 
implements ProgressEventNoti
 
 for (UntypedResultSet.Row r : result)
 {
-if (source.address.equals(r.getInetAddress("source")))
+int port = DatabaseDescriptor.getStoragePort();
+if (r.has("source_port"))
+port = r.getInt("source_port");
+InetAddressAndPort eventNode = 
InetAddressAndPort.getByAddressOverrideDefaults(r.getInetAddress("source"), 
port);
+if (source.equals(eventNode))
 continue;
 if ((uuid = r.getUUID("event_id")).timestamp() > (tcur 
- 1000) * 1)
 seen[si].add(uuid);


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

[jira] [Updated] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14225:
---
Status: Ready to Commit  (was: Patch Available)

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-14225:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14225) fix comparison of address and port for repair and messages

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-14225:


+1 Committed as 
[834f2a6ecdb8974839762bf4e9c5fed32163f9c8|https://github.com/apache/cassandra/commit/834f2a6ecdb8974839762bf4e9c5fed32163f9c8]
 thanks!

> fix comparison of address and port for repair and messages
> --
>
> Key: CASSANDRA-14225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14225
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: 14225.txt
>
>
> compare both host and port, not just host



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14219) Change to AlterTableStatement logging breaks MView tests

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14219:
--

Missed this ticket and accidentally created a duplicate and did the same patch 
yesterday CASSANDRA-14230 It's also broken on trunk FTR.

> Change to AlterTableStatement logging breaks MView tests
> 
>
> Key: CASSANDRA-14219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14219
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> looks like [~dbrosius]'s ninja commit 
> {{7df36056b12a13b60097b7a9a4f8155a1d02ff62}} to improve the logging of 
> {{AlterTableStatement}} breaks some MView tests that check the exception 
> message. I see about six failed tests from {{ViewComplexTest}} that have 
> messages similar to this:
> {noformat}
> junit.framework.AssertionFailedError: Expected error message to contain 
> 'Cannot drop column m on base table with materialized views', but got 'Cannot 
> drop column m on base table table_6 with materialized views.'{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-7622:
-

bq. I'm not really sure a lot of ops people would even notice this new feature 
as long as we don't pull the plug on JMX.
New users would still likely use it over JMX because it would hopefully be more 
user friendly (JMX is pretty ugly). If we could make it perform better than JMX 
that would be a big win (this seems unlikely though). Once people implement the 
tools to gather metrics from it the cost to users for crossing over to the 
vTables would be pretty minimal.

There's no reason to only expose config in cqlsh. Ops people would want to do 
reading and writing to config properties from their own programs, and limiting 
it to cqlsh would be nasty. Being able to use CQL would be ideal for config 
management.

On another note I can think of a couple examples for "replicated vTables" such 
as whole cluster state. At the moment if you want to do any proper monitoring 
on cluster state (down nodes) you have to aggregate all this information 
yourself from every node in the cluster. With replicated vTables we could 
easily store cluster state in a table and update it, making monitoring much 
easier for everyone. This also goes for things like repairs, where we could 
better expose repairs happening across the cluster, nodes, and ranges involved. 
We could probably even use it to better manage repairs that fail (e.g 
automatically kill off validations that are no longer important).

Being able to read and modify config I'd still say is the biggest win however.

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tupshin Harper
>Assignee: Jeff Jirsa
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: (was: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch)

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14219) Change to AlterTableStatement logging breaks MView tests

[Kurt Greaves (JIRA)]

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

Kurt Greaves edited comment on CASSANDRA-14219 at 2/13/18 11:28 PM:


Missed this ticket and accidentally created a duplicate and did the same patch 
yesterday CASSANDRA-14230 It's also broken on trunk FTR.

 

In regards to patch, you can just use currentTable() to get the CF name.


was (Author: kurtg):
Missed this ticket and accidentally created a duplicate and did the same patch 
yesterday CASSANDRA-14230 It's also broken on trunk FTR.

> Change to AlterTableStatement logging breaks MView tests
> 
>
> Key: CASSANDRA-14219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14219
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> looks like [~dbrosius]'s ninja commit 
> {{7df36056b12a13b60097b7a9a4f8155a1d02ff62}} to improve the logging of 
> {{AlterTableStatement}} breaks some MView tests that check the exception 
> message. I see about six failed tests from {{ViewComplexTest}} that have 
> messages similar to this:
> {noformat}
> junit.framework.AssertionFailedError: Expected error message to contain 
> 'Cannot drop column m on base table with materialized views', but got 'Cannot 
> drop column m on base table table_6 with materialized views.'{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14219) Change to AlterTableStatement logging breaks MView tests

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-14219:

   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)
   4.0
   3.11.2
   3.0.16
   Status: Resolved  (was: Patch Available)

+1.Thanks, [~djoshi3]. Committed as sha 
{{890f319142ddd3cf2692ff45ff28e71001365e96}}

For posterity here's my ports to 3.0/3.11/trunk and the test runs; 
{{ViewComplexTest}} no longer fails.

||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/3.0.16-candidate]|[branch|https://github.com/jasobrown/cassandra/tree/3.11.2-candidate]|[branch|https://github.com/jasobrown/cassandra/tree/14291-trunk]|
|[utests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/3.0.16-candidate]|[utests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/3.11.2-candidate]|[utests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14291-trunk]|
||


> Change to AlterTableStatement logging breaks MView tests
> 
>
> Key: CASSANDRA-14219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14219
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> looks like [~dbrosius]'s ninja commit 
> {{7df36056b12a13b60097b7a9a4f8155a1d02ff62}} to improve the logging of 
> {{AlterTableStatement}} breaks some MView tests that check the exception 
> message. I see about six failed tests from {{ViewComplexTest}} that have 
> messages similar to this:
> {noformat}
> junit.framework.AssertionFailedError: Expected error message to contain 
> 'Cannot drop column m on base table with materialized views', but got 'Cannot 
> drop column m on base table table_6 with materialized views.'{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Description: 
Latencies are reported at keyspace level with `ms.` and at table level with 
`ms`.

There should be no trailing `.` as it is not a sentence and `.` is not part of 
the abbreviation.

This is also present in 2.x with `nodetool cfstats`.

  was:
Latencies are reported at keyspace level with `ms.` and at table level with 
`ms`.

There should be no trailing "." as it is not a sentence and "." is not part of 
the abbreviation.

This is also present in 2.x with `nodetool cfstats`.


> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[2/3] cassandra git commit: Fix unit test failures in ViewComplexTest

[jasobrown]

Fix unit test failures in ViewComplexTest

patch by Dinesh Joshi; reviewed by jasobrown for CASSANDRA-14219


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

Branch: refs/heads/cassandra-3.11
Commit: 890f319142ddd3cf2692ff45ff28e71001365e96
Parents: 91e83c7
Author: Dinesh Joshi 
Authored: Fri Feb 9 11:14:12 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:00:57 2018 -0800

--
 CHANGES.txt |  1 +
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 197ba58..90bd53f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix unit test failures in ViewComplexTest (CASSANDRA-14219)
  * Add MinGW uname check to start scripts (CASSANDRA-12940)
  * Protect against overflow of local expiration time (CASSANDRA-14092)
  * Use the correct digest file and reload sstable metadata in nodetool verify 
(CASSANDRA-14217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java 
b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
index 464cc39..bb0e269 100644
--- a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
+++ b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
@@ -319,7 +319,7 @@ public class ViewComplexTest extends CQLTester
 private void testUpdateColumnNotInView(boolean flush) throws Throwable
 {
 // CASSANDRA-13127: if base column not selected in view are alive, 
then pk of view row should be alive
-createTable("create table %s (p int, c int, v1 int, v2 int, primary 
key(p, c))");
+String baseTable = createTable("create table %s (p int, c int, v1 int, 
v2 int, primary key(p, c))");
 
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
@@ -399,7 +399,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p = 
?", 0, 0), row(0, 0, null, 1));
 assertRowsIgnoringOrder(execute("SELECT * from mv WHERE c = ? AND p = 
?", 0, 0), row(0, 0));
 
-assertInvalidMessage("Cannot drop column v2 on base table with 
materialized views", "ALTER TABLE %s DROP v2");
+assertInvalidMessage(String.format("Cannot drop column v2 on base 
table %s with materialized views.", baseTable), "ALTER TABLE %s DROP v2");
 // // drop unselected base column, unselected metadata should be 
removed, thus view row is dead
 // updateView("ALTER TABLE %s DROP v2");
 // assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p 
= ?", 0, 0));
@@ -424,7 +424,7 @@ public class ViewComplexTest extends CQLTester
 {
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
-String baseTableName = createTable("CREATE TABLE %s (k int, c int, a 
int, b int, l list, s set, m map, PRIMARY KEY (k, c))");
+String baseTable = createTable("CREATE TABLE %s (k int, c int, a int, 
b int, l list, s set, m map, PRIMARY KEY (k, c))");
 createView("mv",
"CREATE MATERIALIZED VIEW %s AS SELECT a, b FROM %%s WHERE 
k IS NOT NULL AND c IS NOT NULL PRIMARY KEY (c, k)");
 Keyspace ks = Keyspace.open(keyspace());
@@ -460,7 +460,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s"), row(1, 1, 
null, null));
 assertRowsIgnoringOrder(execute("SELECT * from mv"), row(1, 1, null, 
null));
 
-assertInvalidMessage("Cannot drop column m on base table " + 
baseTableName + " with materialized views", "ALTER TABLE %s DROP m");
+assertInvalidMessage(String.format("Cannot drop column m on base table 
%s with materialized views.", baseTable), "ALTER TABLE %s DROP m");
 // executeNet(protocolVersion, "ALTER TABLE %s DROP m");
 // ks.getColumnFamilyStore("mv").forceMajorCompaction();
 // assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s WHERE k = 1 
AND c = 1"));
@@ -880,7 +880,7 @@ public class ViewComplexTest extends CQLTester
 public void testUpdateWithColumnTimestampBiggerThanPk(boolean flush) 
throws 

[1/3] cassandra git commit: Fix unit test failures in ViewComplexTest

[jasobrown]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 91e83c72d -> 890f31914
  refs/heads/cassandra-3.11 8a5e88f63 -> 30c35dd8a


Fix unit test failures in ViewComplexTest

patch by Dinesh Joshi; reviewed by jasobrown for CASSANDRA-14219


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

Branch: refs/heads/cassandra-3.0
Commit: 890f319142ddd3cf2692ff45ff28e71001365e96
Parents: 91e83c7
Author: Dinesh Joshi 
Authored: Fri Feb 9 11:14:12 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:00:57 2018 -0800

--
 CHANGES.txt |  1 +
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 197ba58..90bd53f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix unit test failures in ViewComplexTest (CASSANDRA-14219)
  * Add MinGW uname check to start scripts (CASSANDRA-12940)
  * Protect against overflow of local expiration time (CASSANDRA-14092)
  * Use the correct digest file and reload sstable metadata in nodetool verify 
(CASSANDRA-14217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java 
b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
index 464cc39..bb0e269 100644
--- a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
+++ b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
@@ -319,7 +319,7 @@ public class ViewComplexTest extends CQLTester
 private void testUpdateColumnNotInView(boolean flush) throws Throwable
 {
 // CASSANDRA-13127: if base column not selected in view are alive, 
then pk of view row should be alive
-createTable("create table %s (p int, c int, v1 int, v2 int, primary 
key(p, c))");
+String baseTable = createTable("create table %s (p int, c int, v1 int, 
v2 int, primary key(p, c))");
 
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
@@ -399,7 +399,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p = 
?", 0, 0), row(0, 0, null, 1));
 assertRowsIgnoringOrder(execute("SELECT * from mv WHERE c = ? AND p = 
?", 0, 0), row(0, 0));
 
-assertInvalidMessage("Cannot drop column v2 on base table with 
materialized views", "ALTER TABLE %s DROP v2");
+assertInvalidMessage(String.format("Cannot drop column v2 on base 
table %s with materialized views.", baseTable), "ALTER TABLE %s DROP v2");
 // // drop unselected base column, unselected metadata should be 
removed, thus view row is dead
 // updateView("ALTER TABLE %s DROP v2");
 // assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p 
= ?", 0, 0));
@@ -424,7 +424,7 @@ public class ViewComplexTest extends CQLTester
 {
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
-String baseTableName = createTable("CREATE TABLE %s (k int, c int, a 
int, b int, l list, s set, m map, PRIMARY KEY (k, c))");
+String baseTable = createTable("CREATE TABLE %s (k int, c int, a int, 
b int, l list, s set, m map, PRIMARY KEY (k, c))");
 createView("mv",
"CREATE MATERIALIZED VIEW %s AS SELECT a, b FROM %%s WHERE 
k IS NOT NULL AND c IS NOT NULL PRIMARY KEY (c, k)");
 Keyspace ks = Keyspace.open(keyspace());
@@ -460,7 +460,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s"), row(1, 1, 
null, null));
 assertRowsIgnoringOrder(execute("SELECT * from mv"), row(1, 1, null, 
null));
 
-assertInvalidMessage("Cannot drop column m on base table " + 
baseTableName + " with materialized views", "ALTER TABLE %s DROP m");
+assertInvalidMessage(String.format("Cannot drop column m on base table 
%s with materialized views.", baseTable), "ALTER TABLE %s DROP m");
 // executeNet(protocolVersion, "ALTER TABLE %s DROP m");
 // ks.getColumnFamilyStore("mv").forceMajorCompaction();
 // assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s WHERE k = 1 
AND c = 1"));
@@ 

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

[jasobrown]

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/30c35dd8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/30c35dd8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/30c35dd8

Branch: refs/heads/cassandra-3.11
Commit: 30c35dd8a4715703aade64e382d58f3db445c88a
Parents: 8a5e88f 890f319
Author: Jason Brown 
Authored: Tue Feb 13 15:02:21 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:07:48 2018 -0800

--
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/30c35dd8/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--


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

[2/4] cassandra git commit: Fix unit test failures in ViewComplexTest

[jasobrown]

Fix unit test failures in ViewComplexTest

patch by Dinesh Joshi; reviewed by jasobrown for CASSANDRA-14219


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

Branch: refs/heads/trunk
Commit: 890f319142ddd3cf2692ff45ff28e71001365e96
Parents: 91e83c7
Author: Dinesh Joshi 
Authored: Fri Feb 9 11:14:12 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:00:57 2018 -0800

--
 CHANGES.txt |  1 +
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 197ba58..90bd53f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix unit test failures in ViewComplexTest (CASSANDRA-14219)
  * Add MinGW uname check to start scripts (CASSANDRA-12940)
  * Protect against overflow of local expiration time (CASSANDRA-14092)
  * Use the correct digest file and reload sstable metadata in nodetool verify 
(CASSANDRA-14217)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/890f3191/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java 
b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
index 464cc39..bb0e269 100644
--- a/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
+++ b/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
@@ -319,7 +319,7 @@ public class ViewComplexTest extends CQLTester
 private void testUpdateColumnNotInView(boolean flush) throws Throwable
 {
 // CASSANDRA-13127: if base column not selected in view are alive, 
then pk of view row should be alive
-createTable("create table %s (p int, c int, v1 int, v2 int, primary 
key(p, c))");
+String baseTable = createTable("create table %s (p int, c int, v1 int, 
v2 int, primary key(p, c))");
 
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
@@ -399,7 +399,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p = 
?", 0, 0), row(0, 0, null, 1));
 assertRowsIgnoringOrder(execute("SELECT * from mv WHERE c = ? AND p = 
?", 0, 0), row(0, 0));
 
-assertInvalidMessage("Cannot drop column v2 on base table with 
materialized views", "ALTER TABLE %s DROP v2");
+assertInvalidMessage(String.format("Cannot drop column v2 on base 
table %s with materialized views.", baseTable), "ALTER TABLE %s DROP v2");
 // // drop unselected base column, unselected metadata should be 
removed, thus view row is dead
 // updateView("ALTER TABLE %s DROP v2");
 // assertRowsIgnoringOrder(execute("SELECT * from %s WHERE c = ? AND p 
= ?", 0, 0));
@@ -424,7 +424,7 @@ public class ViewComplexTest extends CQLTester
 {
 execute("USE " + keyspace());
 executeNet(protocolVersion, "USE " + keyspace());
-String baseTableName = createTable("CREATE TABLE %s (k int, c int, a 
int, b int, l list, s set, m map, PRIMARY KEY (k, c))");
+String baseTable = createTable("CREATE TABLE %s (k int, c int, a int, 
b int, l list, s set, m map, PRIMARY KEY (k, c))");
 createView("mv",
"CREATE MATERIALIZED VIEW %s AS SELECT a, b FROM %%s WHERE 
k IS NOT NULL AND c IS NOT NULL PRIMARY KEY (c, k)");
 Keyspace ks = Keyspace.open(keyspace());
@@ -460,7 +460,7 @@ public class ViewComplexTest extends CQLTester
 assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s"), row(1, 1, 
null, null));
 assertRowsIgnoringOrder(execute("SELECT * from mv"), row(1, 1, null, 
null));
 
-assertInvalidMessage("Cannot drop column m on base table " + 
baseTableName + " with materialized views", "ALTER TABLE %s DROP m");
+assertInvalidMessage(String.format("Cannot drop column m on base table 
%s with materialized views.", baseTable), "ALTER TABLE %s DROP m");
 // executeNet(protocolVersion, "ALTER TABLE %s DROP m");
 // ks.getColumnFamilyStore("mv").forceMajorCompaction();
 // assertRowsIgnoringOrder(execute("SELECT k,c,a,b from %s WHERE k = 1 
AND c = 1"));
@@ -880,7 +880,7 @@ public class ViewComplexTest extends CQLTester
 public void testUpdateWithColumnTimestampBiggerThanPk(boolean flush) 
throws Throwable
 

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

[jasobrown]

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/0bc2164d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0bc2164d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0bc2164d

Branch: refs/heads/trunk
Commit: 0bc2164df244487ef2870c44dfbbd4321378fa49
Parents: 834f2a6 30c35dd
Author: Jason Brown 
Authored: Tue Feb 13 15:38:58 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:41:29 2018 -0800

--
 CHANGES.txt |  1 +
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0bc2164d/CHANGES.txt
--
diff --cc CHANGES.txt
index d7f1f4e,ba72406..54b587d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -208,7 -20,8 +208,8 @@@
   * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
   * Update jackson JSON jars (CASSANDRA-13949)
   * Avoid locks when checking LCS fanout and if we should defrag 
(CASSANDRA-13930)
 - * Correctly count range tombstones in traces and tombstone thresholds 
(CASSANDRA-8527)
  Merged from 3.0:
++ * Fix unit test failures in ViewComplexTest (CASSANDRA-14219)
   * Add MinGW uname check to start scripts (CASSANDRA-12840)
   * Use the correct digest file and reload sstable metadata in nodetool verify 
(CASSANDRA-14217)
   * Handle failure when mutating repaired status in Verifier (CASSANDRA-13933)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0bc2164d/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--


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

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

[jasobrown]

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/30c35dd8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/30c35dd8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/30c35dd8

Branch: refs/heads/trunk
Commit: 30c35dd8a4715703aade64e382d58f3db445c88a
Parents: 8a5e88f 890f319
Author: Jason Brown 
Authored: Tue Feb 13 15:02:21 2018 -0800
Committer: Jason Brown 
Committed: Tue Feb 13 15:07:48 2018 -0800

--
 .../unit/org/apache/cassandra/cql3/ViewComplexTest.java | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/30c35dd8/test/unit/org/apache/cassandra/cql3/ViewComplexTest.java
--


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

[1/4] cassandra git commit: Use new token allocation for non bootstrap case as well.

[jasobrown]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 834f2a6ec -> 0bc2164df


Use new token allocation for non bootstrap case as well.

> patch by Dikang Gu; reviewed by Branimir Lambov for CASSANSRA-13080
backported by Mick Semb Wever; reviewed by Jon Haddad for CASSANSRA-14212


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

Branch: refs/heads/trunk
Commit: 8a5e88f635fdb984505a99a553b5799cedccd06d
Parents: f6ec5c5
Author: Dikang Gu 
Authored: Tue Dec 27 11:55:13 2016 -0800
Committer: Mick Semb Wever 
Committed: Tue Feb 13 08:02:02 2018 +1100

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/dht/BootStrapper.java  | 18 +++--
 .../dht/tokenallocator/TokenAllocation.java |  3 -
 .../cassandra/service/StorageService.java   | 69 +---
 .../apache/cassandra/dht/BootStrapperTest.java  |  2 +-
 5 files changed, 48 insertions(+), 45 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8a5e88f6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bce7e1d..ba72406 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.11.2
+ * Backport CASSANDRA-13080: Use new token allocation for non bootstrap case 
as well (CASSANDRA-14212)
  * Remove dependencies on JVM internal classes from JMXServerUtils 
(CASSANDRA-14173) 
  * Add DEFAULT, UNSET, MBEAN and MBEANS to `ReservedKeywords` (CASSANDRA-14205)
  * Add Unittest for schema migration fix (CASSANDRA-14140)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8a5e88f6/src/java/org/apache/cassandra/dht/BootStrapper.java
--
diff --git a/src/java/org/apache/cassandra/dht/BootStrapper.java 
b/src/java/org/apache/cassandra/dht/BootStrapper.java
index 392dbf2..1e00f48 100644
--- a/src/java/org/apache/cassandra/dht/BootStrapper.java
+++ b/src/java/org/apache/cassandra/dht/BootStrapper.java
@@ -33,12 +33,15 @@ import org.apache.cassandra.db.TypeSizes;
 import org.apache.cassandra.dht.tokenallocator.TokenAllocation;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.gms.FailureDetector;
+import org.apache.cassandra.gms.Gossiper;
 import org.apache.cassandra.io.IVersionedSerializer;
 import org.apache.cassandra.io.util.DataInputPlus;
 import org.apache.cassandra.io.util.DataOutputPlus;
 import org.apache.cassandra.locator.AbstractReplicationStrategy;
 import org.apache.cassandra.locator.TokenMetadata;
+import org.apache.cassandra.service.StorageService;
 import org.apache.cassandra.streaming.*;
+import org.apache.cassandra.utils.FBUtilities;
 import org.apache.cassandra.utils.progress.ProgressEvent;
 import org.apache.cassandra.utils.progress.ProgressEventNotifierSupport;
 import org.apache.cassandra.utils.progress.ProgressEventType;
@@ -155,7 +158,7 @@ public class BootStrapper extends 
ProgressEventNotifierSupport
  * otherwise, if allocationKeyspace is specified use the token allocation 
algorithm to generate suitable tokens
  * else choose num_tokens tokens at random
  */
-public static Collection getBootstrapTokens(final TokenMetadata 
metadata, InetAddress address) throws ConfigurationException
+public static Collection getBootstrapTokens(final TokenMetadata 
metadata, InetAddress address, int schemaWaitDelay) throws 
ConfigurationException
 {
 String allocationKeyspace = 
DatabaseDescriptor.getAllocateTokensForKeyspace();
 Collection initialTokens = 
DatabaseDescriptor.getInitialTokens();
@@ -171,7 +174,7 @@ public class BootStrapper extends 
ProgressEventNotifierSupport
 throw new ConfigurationException("num_tokens must be >= 1");
 
 if (allocationKeyspace != null)
-return allocateTokens(metadata, address, allocationKeyspace, 
numTokens);
+return allocateTokens(metadata, address, allocationKeyspace, 
numTokens, schemaWaitDelay);
 
 if (numTokens == 1)
 logger.warn("Picking random token for a single vnode.  You should 
probably add more vnodes and/or use the automatic token allocation mechanism.");
@@ -182,7 +185,7 @@ public class BootStrapper extends 
ProgressEventNotifierSupport
 private static Collection getSpecifiedTokens(final TokenMetadata 
metadata,
 Collection 
initialTokens)
 {
-logger.trace("tokens manually specified as {}",  initialTokens);
+logger.info("tokens manually specified as {}",  initialTokens);
 

[jira] [Updated] (CASSANDRA-14230) ViewComplexTest broken in trunk

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-14230:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks for the patch, [~KurtG], but I think we beat you to it ;)

> ViewComplexTest broken in trunk
> ---
>
> Key: CASSANDRA-14230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14230
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> testUpdateWithColumnTimestampBiggerThanPkWithFlush
> testUpdateWithColumnTimestampBiggerThanPkWithoutFlush
> testUpdateColumnNotInViewWithFlush
> testUpdateColumnNotInViewWithoutFlush
> All fail with:
> {code}
> [junit] junit.framework.AssertionFailedError: Expected error message to 
> contain 'Cannot drop column v2 on base table with materialized views', but 
> got 'Cannot drop column v2 on base table table_20 with materialized views.'
> {code}
> Because the error message changed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14219) Change to AlterTableStatement logging breaks MView tests

[Dinesh Joshi (JIRA)]

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

Dinesh Joshi commented on CASSANDRA-14219:
--

[~KurtG] I originally used \{{currentTable()}} but then followed the pattern 
you had in other commits.

> Change to AlterTableStatement logging breaks MView tests
> 
>
> Key: CASSANDRA-14219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14219
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> looks like [~dbrosius]'s ninja commit 
> {{7df36056b12a13b60097b7a9a4f8155a1d02ff62}} to improve the logging of 
> {{AlterTableStatement}} breaks some MView tests that check the exception 
> message. I see about six failed tests from {{ViewComplexTest}} that have 
> messages similar to this:
> {noformat}
> junit.framework.AssertionFailedError: Expected error message to contain 
> 'Cannot drop column m on base table with materialized views', but got 'Cannot 
> drop column m on base table table_6 with materialized views.'{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-14233:
---

Can you just make it for trunk? 2.0 isnt taking changes anymore and 2.1 is 
pretty much reserved to data loss bugs.

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Kurt Greaves (JIRA)]

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

Kurt Greaves updated CASSANDRA-14234:
-
 Reviewer: Jason Brown
Reproduced In: 3.11.x
   Status: Patch Available  (was: In Progress)

[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...kgreav:14234-3.11]

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Kurt Greaves (JIRA)]

Kurt Greaves created CASSANDRA-14234:


 Summary: ReadCommandTest::testCountWithNoDeletedRow broken
 Key: CASSANDRA-14234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
 Project: Cassandra
  Issue Type: Bug
Reporter: Kurt Greaves
Assignee: Kurt Greaves


{code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
at 
org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Chris Lohfink (JIRA)]

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

Chris Lohfink reassigned CASSANDRA-14233:
-

Assignee: Samuel Roberts

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Chris Lohfink (JIRA)]

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

Chris Lohfink updated CASSANDRA-14233:
--
Reviewer: Chris Lohfink

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14231) After ddl cluster.getMetadata().checkSchemaAgreement() returns true but schema is not in agreement

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa edited comment on CASSANDRA-14231 at 2/14/18 7:45 AM:
-

I suspect you're trying to use the Datastax java driver based on the 
[signature|https://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/Metadata.html#checkSchemaAgreement--]

The Apache Cassandra project doesn't own that driver, and can't make changes to 
it. Your best bet is to contact Datastax and file a bug report 
[there|https://datastax-oss.atlassian.net/projects/JAVA/issues/JAVA?filter=allopenissues]

If you have reason to believe this is really a cassandra bug, and not a driver 
bug, please re-open.



was (Author: jjirsa):
I suspect you're trying to use the Datastax java driver based on the 
[signature|https://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/Metadata.html#checkSchemaAgreement--]

The Apache Cassandra project doesn't own that driver, and can't make changes to 
it. Your best bet is to contact Datastax and file a bug report 
[there|https://datastax-oss.atlassian.net/projects/JAVA/issues/JAVA?filter=allopenissues]

> After ddl cluster.getMetadata().checkSchemaAgreement() returns true but 
> schema is not in agreement
> --
>
> Key: CASSANDRA-14231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14231
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: George Shuklin
>Priority: Major
> Fix For: 3.10
>
>
> We run a set of ddl statements and after each of them wait until schema come 
> to agreement. However periodically after Cluster says that schema is in 
> agreement and we run next DDL statement, it fails as previous DDL did not 
> work properly. 
> The most typical scenario when this problem happens almost always: first DDL 
> drops a table, and next DDL creates it (and cassandra says that this table 
> already exists).
>  
> This is our code to wait:
> private void waitForSchemaAgreement()
>  {
> while (!icluster.getMetadata().checkSchemaAgreement()) {
> try {
>  Thread.sleep(waitTime*1000);
>  } catch (Exception e){
> // ignore  } } }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (CASSANDRA-14231) After ddl cluster.getMetadata().checkSchemaAgreement() returns true but schema is not in agreement

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa resolved CASSANDRA-14231.

Resolution: Invalid

> After ddl cluster.getMetadata().checkSchemaAgreement() returns true but 
> schema is not in agreement
> --
>
> Key: CASSANDRA-14231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14231
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: George Shuklin
>Priority: Major
> Fix For: 3.10
>
>
> We run a set of ddl statements and after each of them wait until schema come 
> to agreement. However periodically after Cluster says that schema is in 
> agreement and we run next DDL statement, it fails as previous DDL did not 
> work properly. 
> The most typical scenario when this problem happens almost always: first DDL 
> drops a table, and next DDL creates it (and cassandra says that this table 
> already exists).
>  
> This is our code to wait:
> private void waitForSchemaAgreement()
>  {
> while (!icluster.getMetadata().checkSchemaAgreement()) {
> try {
>  Thread.sleep(waitTime*1000);
>  } catch (Exception e){
> // ignore  } } }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: 0001-Resolve-nodetool-formatting-in-CASSANDRA-14233.patch

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
> Attachments: 0001-Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14200) NullPointerException when dumping sstable with null value for timestamp column

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-14200:


Before we paper over a potentially larger issue, how did you get a cell with a 
null timestamp?


> NullPointerException when dumping sstable with null value for timestamp column
> --
>
> Key: CASSANDRA-14200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14200
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Major
> Fix For: 3.0.x
>
>
> We have an sstable whose schema has a column of type timestamp and it's not 
> part of primary key. When dumping the sstable using sstabledump there is NPE 
> like this:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:1770)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:943)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at 
> org.apache.cassandra.db.marshal.TimestampType.toJSONString(TimestampType.java:93)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeCell(JsonTransformer.java:442)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeColumnData(JsonTransformer.java:376)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:280)
> at 
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:215)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at 
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:104)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:242){code}
> The reason is that we use a null Date when there is no value for this column:
> {code}
> public Date deserialize(ByteBuffer bytes)
> {
> return bytes.remaining() == 0 ? null : new 
> Date(ByteBufferUtil.toLong(bytes));
> }
> {code}
> It seems that we should not deserialize columns with null values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: (was: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch)

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
> Attachments: 0001-Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-14233:


GitHub user sproberts92 opened a pull request:

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

Resolve nodetool formatting in CASSANDRA-14233

Remove trailing "." from latency reports at keyspace level.

For 
[CASSANDRA-14233](https://issues.apache.org/jira/browse/CASSANDRA-14233).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sproberts92/cassandra CASSANDRA-14233

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/195.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #195


commit ae6e74ac0f31161be10481f2f4c76cebfe45d7b0
Author: Samuel Roberts 
Date:   2018-02-14T06:44:50Z

Resolve nodetool formatting in CASSANDRA-14233

Remove trailing "." from latency reports at keyspace level.




> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
> Attachments: Resolve-nodetool-formatting-in-CASSANDRA-14233.patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14231) After ddl cluster.getMetadata().checkSchemaAgreement() returns true but schema is not in agreement

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-14231:


I suspect you're trying to use the Datastax java driver based on the 
[signature|https://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/Metadata.html#checkSchemaAgreement--]

The Apache Cassandra project doesn't own that driver, and can't make changes to 
it. Your best bet is to contact Datastax and file a bug report 
[there|https://datastax-oss.atlassian.net/projects/JAVA/issues/JAVA?filter=allopenissues]

> After ddl cluster.getMetadata().checkSchemaAgreement() returns true but 
> schema is not in agreement
> --
>
> Key: CASSANDRA-14231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14231
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: George Shuklin
>Priority: Major
> Fix For: 3.10
>
>
> We run a set of ddl statements and after each of them wait until schema come 
> to agreement. However periodically after Cluster says that schema is in 
> agreement and we run next DDL statement, it fails as previous DDL did not 
> work properly. 
> The most typical scenario when this problem happens almost always: first DDL 
> drops a table, and next DDL creates it (and cassandra says that this table 
> already exists).
>  
> This is our code to wait:
> private void waitForSchemaAgreement()
>  {
> while (!icluster.getMetadata().checkSchemaAgreement()) {
> try {
>  Thread.sleep(waitTime*1000);
>  } catch (Exception e){
> // ignore  } } }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa reassigned CASSANDRA-13929:
--

Assignee: Jay Zhuang

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Jay Zhuang
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_NORECYCLE_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_snapshot_heaputilization.png, 
> cassandra_3.11.1_vs_3.11.2recyclernullingpatch.png, 
> dtest_example_80_request.png, dtest_example_80_request_fix.png, 
> dtest_example_heap.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-13929:


[~tsteinmaurer] - available to test?

Patch looks straight forward to me, but any volunteers to review? Given its 
impact, probably deserves a more thorough review than I have time for. 




> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Jay Zhuang
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_NORECYCLE_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_snapshot_heaputilization.png, 
> cassandra_3.11.1_vs_3.11.2recyclernullingpatch.png, 
> dtest_example_80_request.png, dtest_example_80_request_fix.png, 
> dtest_example_heap.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Norman Maurer (JIRA)]

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

Norman Maurer commented on CASSANDRA-13929:
---

[~jay.zhuang] I would be interested what is contained in the `Stack` itself

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Jay Zhuang
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_NORECYCLE_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_snapshot_heaputilization.png, 
> cassandra_3.11.1_vs_3.11.2recyclernullingpatch.png, 
> dtest_example_80_request.png, dtest_example_80_request_fix.png, 
> dtest_example_heap.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-13929) BTree$Builder / io.netty.util.Recycler$Stack leaking memory

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-13929:
---
Status: Patch Available  (was: Awaiting Feedback)

> BTree$Builder / io.netty.util.Recycler$Stack leaking memory
> ---
>
> Key: CASSANDRA-13929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Thomas Steinmaurer
>Assignee: Jay Zhuang
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: cassandra_3.11.0_min_memory_utilization.jpg, 
> cassandra_3.11.1_NORECYCLE_memory_utilization.jpg, 
> cassandra_3.11.1_mat_dominator_classes.png, 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png, 
> cassandra_3.11.1_snapshot_heaputilization.png, 
> cassandra_3.11.1_vs_3.11.2recyclernullingpatch.png, 
> dtest_example_80_request.png, dtest_example_80_request_fix.png, 
> dtest_example_heap.png
>
>
> Different to CASSANDRA-13754, there seems to be another memory leak in 
> 3.11.0+ in BTree$Builder / io.netty.util.Recycler$Stack.
> * heap utilization increase after upgrading to 3.11.0 => 
> cassandra_3.11.0_min_memory_utilization.jpg
> * No difference after upgrading to 3.11.1 (snapshot build) => 
> cassandra_3.11.1_snapshot_heaputilization.png; thus most likely after fixing 
> CASSANDRA-13754, more visible now
> * MAT shows io.netty.util.Recycler$Stack as top contributing class => 
> cassandra_3.11.1_mat_dominator_classes.png
> * With -Xmx8G (CMS) and our load pattern, we have to do a rolling restart 
> after ~ 72 hours
> Verified the following fix, namely explicitly unreferencing the 
> _recycleHandle_ member (making it non-final). In 
> _org.apache.cassandra.utils.btree.BTree.Builder.recycle()_
> {code}
> public void recycle()
> {
> if (recycleHandle != null)
> {
> this.cleanup();
> builderRecycler.recycle(this, recycleHandle);
> recycleHandle = null; // ADDED
> }
> }
> {code}
> Patched a single node in our loadtest cluster with this change and after ~ 10 
> hours uptime, no sign of the previously offending class in MAT anymore => 
> cassandra_3.11.1_mat_dominator_classes_FIXED.png
> Can' say if this has any other side effects etc., but I doubt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14233) nodetool tablestats/cfstats output has inconsistent formatting for latency

[Samuel Roberts (JIRA)]

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

Samuel Roberts updated CASSANDRA-14233:
---
Attachment: (was: 
0001-Resolve-nodetool-formatting-in-CASSANDRA-14233.patch)

> nodetool tablestats/cfstats output has inconsistent formatting for latency
> --
>
> Key: CASSANDRA-14233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14233
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Roberts
>Assignee: Samuel Roberts
>Priority: Trivial
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> Latencies are reported at keyspace level with `ms.` and at table level with 
> `ms`.
> There should be no trailing `.` as it is not a sentence and `.` is not part 
> of the abbreviation.
> This is also present in 2.x with `nodetool cfstats`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14234:
--

[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:14234-trunk]
Sorry 'bout that. Not sure why I naively expected it to merge up cleanly.

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-14234:
---
Fix Version/s: 4.0
   3.11.2
   3.0.16

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14234) ReadCommandTest::testCountWithNoDeletedRow broken

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-14234:
---
Fix Version/s: (was: 3.0.16)

> ReadCommandTest::testCountWithNoDeletedRow broken
> -
>
> Key: CASSANDRA-14234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14234
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
>Priority: Major
> Fix For: 3.11.2, 4.0
>
>
> {code}junit.framework.AssertionFailedError: expected:<1> but was:<5>
>   at 
> org.apache.cassandra.db.ReadCommandTest.testCountWithNoDeletedRow(ReadCommandTest.java:336){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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