[jira] [Created] (CASSANDRA-11749) CQLSH gets SSL exception following a COPY FROM

[Stefania (JIRA)]

Stefania created CASSANDRA-11749:


 Summary: CQLSH gets SSL exception following a COPY FROM
 Key: CASSANDRA-11749
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11749
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Stefania
Assignee: Stefania
 Fix For: 2.1.x


When running Cassandra and cqlsh with SSL, the following command occasionally 
results in the exception below:

{code}
cqlsh --ssl -f kv.cql
{code}


{code}
ERROR [SharedPool-Worker-2] 2016-05-11 12:41:03,583 Message.java:538 - 
Unexpected exception during request; channel = [id: 0xeb75e05d, 
/127.0.0.1:51083 => /127.0.0.1:9042]
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException: bad record 
MAC
at 
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:280)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:722)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: javax.net.ssl.SSLException: bad record MAC
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) 
~[na:1.8.0_91]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) 
~[na:1.8.0_91]
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:981) 
~[na:1.8.0_91]
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907) 
~[na:1.8.0_91]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) 
~[na:1.8.0_91]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_91]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:982) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:908) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:854) 
~[netty-all-4.0.23.Final.jar:4.0.23.Final]
at 
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:249)
 ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
... 10 common frames omitted
Caused by: javax.crypto.BadPaddingException: bad record MAC
at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219) 
~[na:1.8.0_91]
at 
sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177) 
~[na:1.8.0_91]
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:974) 
~[na:1.8.0_91]
... 17 common frames omitted
{code}

where

{code}
cat kv.cql 
create keyspace if not exists cvs_copy_ks with replication = {'class': 
'SimpleStrategy', 'replication_factor':1};
create table if not exists cvs_copy_ks.kv (key int primary key, value text);
truncate cvs_copy_ks.kv;
copy cvs_copy_ks.kv (key, value) from 'kv.csv' with header='true';
select * from cvs_copy_ks.kv;
drop keyspace cvs_copy_ks;
stefi@cuoricina:~/git/cstar/cassandra$ cat kv.c
kv.cql  kv.csv  

cat kv.csv 
key,value
1,'a'
2,'b'
3,'c'
{code}

The COPY FROM succeeds, however the following select does not. 

The easiest way to reproduce this is to restart the Cassandra process, it seems 
to happen in preference after a restart.



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

[jira] [Comment Edited] (CASSANDRA-6862) Schema versions mismatch on large ring

[Michael Fong (JIRA)]

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

Michael Fong edited comment on CASSANDRA-6862 at 5/11/16 4:29 AM:
--

Hi,

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at CASSANDRA-11748

Has anyone observed the heap over usage on exchanging schema information before?


was (Author: michael.fong):
Hi,

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at CASSANDRA-11748

Have you observed the heap over usage on exchanging schema information before?

> Schema versions mismatch on large ring
> --
>
> Key: CASSANDRA-6862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6862
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.0
>Reporter: Oleg Anastasyev
>Assignee: Oleg Anastasyev
> Fix For: 2.0.7
>
> Attachments: 6862-v2.txt, SchemaVersionLiveColumns.txt
>
>
> We have a large cluster with several hundreds nodes in 1 ring. Sometimes, 
> especially after massive restarts, schema versions reported on different 
> nodes mismatch.
> Investigated and found, that difference is not in schema itsself, but in 
> thombstones (different nodes have different set of thombstones applied to 
> system tables).
> Fixed by digesting schema with thombstones removed first.



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

[jira] [Commented] (CASSANDRA-6862) Schema versions mismatch on large ring

[Michael Fong (JIRA)]

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

Michael Fong commented on CASSANDRA-6862:
-

Hi,

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at CASSANDRA-11748

Have you observed the heap over usage on exchanging schema information before?

> Schema versions mismatch on large ring
> --
>
> Key: CASSANDRA-6862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6862
> Project: Cassandra
>  Issue Type: Bug
> Environment: 2.0
>Reporter: Oleg Anastasyev
>Assignee: Oleg Anastasyev
> Fix For: 2.0.7
>
> Attachments: 6862-v2.txt, SchemaVersionLiveColumns.txt
>
>
> We have a large cluster with several hundreds nodes in 1 ring. Sometimes, 
> especially after massive restarts, schema versions reported on different 
> nodes mismatch.
> Investigated and found, that difference is not in schema itsself, but in 
> thombstones (different nodes have different set of thombstones applied to 
> system tables).
> Fixed by digesting schema with thombstones removed first.



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

[jira] [Comment Edited] (CASSANDRA-8165) Do not include tombstones in schema version computation

[Michael Fong (JIRA)]

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

Michael Fong edited comment on CASSANDRA-8165 at 5/11/16 4:12 AM:
--

Hi, 

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at CASSANDRA-11748

Have you observed the OOM situation before?



was (Author: michael.fong):
Hi, 

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at 
https://issues.apache.org/jira/browse/CASSANDRA-11748


> Do not include tombstones in schema version computation
> ---
>
> Key: CASSANDRA-8165
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8165
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vishy Kasar
>
> During 1.2.19 migration, we found the schema version mismatch issue. On 
> digging further, Sankalp found this was due to inclusion of the tombstones by 
> 1.2.19 due to increased gc_grace_seconds. 
> It seems wrong to include ephemeral data like tombstones in MD5 computation. 
> Can this be avoided?



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

[jira] [Commented] (CASSANDRA-8165) Do not include tombstones in schema version computation

[Michael Fong (JIRA)]

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

Michael Fong commented on CASSANDRA-8165:
-

Hi, 

We have recently seen schema version mismatch issue while doing rolling upgrade 
from 1.2.19 to 2.0.17. What is worse is that the mismatch could lead to a rapid 
and massive message exchange of schema information across nodes, and sometimes 
may lead to node OOM. I opened a ticket regarding this at 
https://issues.apache.org/jira/browse/CASSANDRA-11748


> Do not include tombstones in schema version computation
> ---
>
> Key: CASSANDRA-8165
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8165
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vishy Kasar
>
> During 1.2.19 migration, we found the schema version mismatch issue. On 
> digging further, Sankalp found this was due to inclusion of the tombstones by 
> 1.2.19 due to increased gc_grace_seconds. 
> It seems wrong to include ephemeral data like tombstones in MD5 computation. 
> Can this be avoided?



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

[jira] [Updated] (CASSANDRA-11055) C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no attribute 'replace'

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11055:
-
Reviewer: Adam Holmberg
  Status: Patch Available  (was: In Progress)

> C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no 
> attribute 'replace'
> ---
>
> Key: CASSANDRA-11055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11055
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Simon Ashley
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 11055-driver-2.7.2.patch, data.tar.gz
>
>
> C* 2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns:
>  'NoneType' object has no attribute 'replace' 
> for thrift CF's originally created in C* 1.2.
> Repro:
> 1. Create cf in cassandra-cli on C* 1.2.x  (1.2.9 was used here)
> [default@ks1] CREATE COLUMN FAMILY t1
> ...   WITH column_type='Standard'
> ...   AND 
> comparator='CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type)'
> ...   AND default_validation_class='UTF8Type'
> ...   AND key_validation_class='UTF8Type'
> ...   AND read_repair_chance=0.1
> ...   AND dclocal_read_repair_chance=0.0
> ...   AND gc_grace=864000
> ...   AND min_compaction_threshold=4
> ...   AND max_compaction_threshold=32
> ...   AND replicate_on_write=true
> ...   AND compaction_strategy='LeveledCompactionStrategy' AND 
> compaction_strategy_options={sstable_size_in_mb: 32}
> ...   AND caching='KEYS_ONLY'
> ...   AND compression_options={sstable_compression:SnappyCompressor, 
> chunk_length_kb:64};
> qlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {
>   'class': 'NetworkTopologyStrategy',
>   'datacenter1': '1'
> };
> USE ks1;
> CREATE TABLE t1 (
>   key text,
>   column1 text,
>   column2 text,
>   value text,
>   PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=0.10 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '32', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '64', 'sstable_compression': 
> 'SnappyCompressor'};
> cqlsh> select keyspace_name, columnfamily_name,column_aliases,key_aliases 
> from system.schema_columnfamilies where keyspace_name= 'ks1';
>  keyspace_name | columnfamily_name | column_aliases | key_aliases
> ---+---++-
>ks1 |t1 | [] |  []
> 2/ Upgrade -> C* 2.0.9 -> nodetool upgradesstables -a
> At this stage , DESCRIBE in cqlsh is working
> 3/ Upgrade -> C* 2.1.12 -> nodetool upgradesstables -a
> DESCRIBE now fails:
> cqlsh> describe table ks1.t1;
> 'NoneType' object has no attribute 'replace'
> cqlsh> describe keyspace ks1;
> 'NoneType' object has no attribute 'replace'
> You can workaround by manually updating system.schema_columnfamilies
>  UPDATE system.schema_columnfamilies SET column_aliases 
> ='["column1","column2"]' WHERE keyspace_name = 'ks1' AND columnfamily_name = 
> 't1';
> Once you exit and restart cqlsh, DESCRIBE is not working as per C* 1.2
> cqlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1'}  AND durable_writes = true;
> CREATE TABLE ks1.t1 (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'sstable_size_in_mb': '32', 'class': 
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression': 
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.1
> AND speculative_retry = '99.0PERCENTILE';



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

[jira] [Updated] (CASSANDRA-11055) C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no attribute 'replace'

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11055:
-
Component/s: Tools

> C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no 
> attribute 'replace'
> ---
>
> Key: CASSANDRA-11055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11055
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Simon Ashley
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 11055-driver-2.7.2.patch, data.tar.gz
>
>
> C* 2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns:
>  'NoneType' object has no attribute 'replace' 
> for thrift CF's originally created in C* 1.2.
> Repro:
> 1. Create cf in cassandra-cli on C* 1.2.x  (1.2.9 was used here)
> [default@ks1] CREATE COLUMN FAMILY t1
> ...   WITH column_type='Standard'
> ...   AND 
> comparator='CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type)'
> ...   AND default_validation_class='UTF8Type'
> ...   AND key_validation_class='UTF8Type'
> ...   AND read_repair_chance=0.1
> ...   AND dclocal_read_repair_chance=0.0
> ...   AND gc_grace=864000
> ...   AND min_compaction_threshold=4
> ...   AND max_compaction_threshold=32
> ...   AND replicate_on_write=true
> ...   AND compaction_strategy='LeveledCompactionStrategy' AND 
> compaction_strategy_options={sstable_size_in_mb: 32}
> ...   AND caching='KEYS_ONLY'
> ...   AND compression_options={sstable_compression:SnappyCompressor, 
> chunk_length_kb:64};
> qlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {
>   'class': 'NetworkTopologyStrategy',
>   'datacenter1': '1'
> };
> USE ks1;
> CREATE TABLE t1 (
>   key text,
>   column1 text,
>   column2 text,
>   value text,
>   PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=0.10 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '32', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '64', 'sstable_compression': 
> 'SnappyCompressor'};
> cqlsh> select keyspace_name, columnfamily_name,column_aliases,key_aliases 
> from system.schema_columnfamilies where keyspace_name= 'ks1';
>  keyspace_name | columnfamily_name | column_aliases | key_aliases
> ---+---++-
>ks1 |t1 | [] |  []
> 2/ Upgrade -> C* 2.0.9 -> nodetool upgradesstables -a
> At this stage , DESCRIBE in cqlsh is working
> 3/ Upgrade -> C* 2.1.12 -> nodetool upgradesstables -a
> DESCRIBE now fails:
> cqlsh> describe table ks1.t1;
> 'NoneType' object has no attribute 'replace'
> cqlsh> describe keyspace ks1;
> 'NoneType' object has no attribute 'replace'
> You can workaround by manually updating system.schema_columnfamilies
>  UPDATE system.schema_columnfamilies SET column_aliases 
> ='["column1","column2"]' WHERE keyspace_name = 'ks1' AND columnfamily_name = 
> 't1';
> Once you exit and restart cqlsh, DESCRIBE is not working as per C* 1.2
> cqlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1'}  AND durable_writes = true;
> CREATE TABLE ks1.t1 (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'sstable_size_in_mb': '32', 'class': 
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression': 
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.1
> AND speculative_retry = '99.0PERCENTILE';



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

[jira] [Commented] (CASSANDRA-11055) C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no attribute 'replace'

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11055:
--

This is the exception stack trace:

{code}
raceback (most recent call last):
  File "/home/stefi/git/cstar/cassandra/bin/cqlsh", line 1010, in onecmd
self.handle_statement(st, statementtext)
  File "/home/stefi/git/cstar/cassandra/bin/cqlsh", line 1047, in 
handle_statement
return custom_handler(parsed)
  File "/home/stefi/git/cstar/cassandra/bin/cqlsh", line 1475, in do_describe
self.describe_keyspace(ksname)
  File "/home/stefi/git/cstar/cassandra/bin/cqlsh", line 1317, in 
describe_keyspace
self.print_recreate_keyspace(self.get_keyspace_meta(ksname), sys.stdout)
  File "/home/stefi/git/cstar/cassandra/bin/cqlsh", line 1277, in 
print_recreate_keyspace
out.write(ksdef.export_as_string())
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 875, in export_as_string
+ [t.export_as_string() for t in self.tables.values()])
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1302, in export_as_string
ret += "\nApproximate structure, for reference:\n(this should not be used 
to reproduce this schema)\n\n%s\n*/" % self.all_as_cql()
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1309, in all_as_cql
ret = self.as_cql_query(formatted=True)
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1340, in as_cql_query
columns.append("%s %s%s" % (protect_name(col.name), col.typestring, ' 
static' if col.is_static else ''))
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1430, in protect_name
return maybe_escape_name(name)
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1459, in maybe_escape_name
return escape_name(name)
  File 
"/home/stefi/git/cstar/cassandra/bin/../lib/cassandra-driver-internal-only-2.7.2.zip/cassandra-driver-2.7.2/cassandra/metadata.py",
 line 1463, in escape_name
return '"%s"' % (name.replace('"', '""'),)
AttributeError: 'NoneType' object has no attribute 'replace'
{code}

It is caused by {{ColumnMetadata}} instances where the name is set to {{None}}. 
I've attached [^data.tar.gz], it contains a data directory with a CF that was 
generated in 1.2.9 following the instructions in the description and it can be 
used to reproduce the problem in 2.1 HEAD.

[~aholmber]: the problem is in {{_build_table_metadata()}}, see patch attached 
([^11055-driver-2.7.2.patch]). In the absence of column aliases, we pick up an 
array set to {{\[None, None\]}} from {{comparator.fieldnames}}. I've fixed it 
so that it gets the column names from the clustering rows but you may want to 
check the contents of {{comparator.fieldnames}} before using it. Also, when 
processing the normal columns, {{cf_col_rows}}, shouldn't we skip clustering 
and partition columns?

*The exception does not happen in 2.2 HEAD*, so I am not sure how much of this 
patch is required in the latest driver version.

Due to the API changes in the 3.0+ driver, I would prefer to apply this patch 
to the 2.7.2 branch rather than upgrade the bundled driver in 2.1 to 3.0, is 
this OK [~aholmber]? 

> C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no 
> attribute 'replace'
> ---
>
> Key: CASSANDRA-11055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11055
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 11055-driver-2.7.2.patch, data.tar.gz
>
>
> C* 2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns:
>  'NoneType' object has no attribute 'replace' 
> for thrift CF's originally created in C* 1.2.
> Repro:
> 1. Create cf in cassandra-cli on C* 1.2.x  (1.2.9 was used here)
> [default@ks1] CREATE COLUMN FAMILY t1
> ...   WITH column_type='Standard'
> ...   AND 
> comparator='CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type)'
> ...   AND default_validation_class='UTF8Type'
> ...   AND key_validation_class='UTF8Type'
> ...   AND read_repair_chance=0.1
> ...   AND dclocal_read_repair_chance=0.0
> ...   AND gc_grace=864000
> ...   AND 

[jira] [Updated] (CASSANDRA-11055) C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no attribute 'replace'

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11055:
-
Attachment: data.tar.gz
11055-driver-2.7.2.patch

> C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no 
> attribute 'replace'
> ---
>
> Key: CASSANDRA-11055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11055
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 11055-driver-2.7.2.patch, data.tar.gz
>
>
> C* 2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns:
>  'NoneType' object has no attribute 'replace' 
> for thrift CF's originally created in C* 1.2.
> Repro:
> 1. Create cf in cassandra-cli on C* 1.2.x  (1.2.9 was used here)
> [default@ks1] CREATE COLUMN FAMILY t1
> ...   WITH column_type='Standard'
> ...   AND 
> comparator='CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type)'
> ...   AND default_validation_class='UTF8Type'
> ...   AND key_validation_class='UTF8Type'
> ...   AND read_repair_chance=0.1
> ...   AND dclocal_read_repair_chance=0.0
> ...   AND gc_grace=864000
> ...   AND min_compaction_threshold=4
> ...   AND max_compaction_threshold=32
> ...   AND replicate_on_write=true
> ...   AND compaction_strategy='LeveledCompactionStrategy' AND 
> compaction_strategy_options={sstable_size_in_mb: 32}
> ...   AND caching='KEYS_ONLY'
> ...   AND compression_options={sstable_compression:SnappyCompressor, 
> chunk_length_kb:64};
> qlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {
>   'class': 'NetworkTopologyStrategy',
>   'datacenter1': '1'
> };
> USE ks1;
> CREATE TABLE t1 (
>   key text,
>   column1 text,
>   column2 text,
>   value text,
>   PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=0.10 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '32', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '64', 'sstable_compression': 
> 'SnappyCompressor'};
> cqlsh> select keyspace_name, columnfamily_name,column_aliases,key_aliases 
> from system.schema_columnfamilies where keyspace_name= 'ks1';
>  keyspace_name | columnfamily_name | column_aliases | key_aliases
> ---+---++-
>ks1 |t1 | [] |  []
> 2/ Upgrade -> C* 2.0.9 -> nodetool upgradesstables -a
> At this stage , DESCRIBE in cqlsh is working
> 3/ Upgrade -> C* 2.1.12 -> nodetool upgradesstables -a
> DESCRIBE now fails:
> cqlsh> describe table ks1.t1;
> 'NoneType' object has no attribute 'replace'
> cqlsh> describe keyspace ks1;
> 'NoneType' object has no attribute 'replace'
> You can workaround by manually updating system.schema_columnfamilies
>  UPDATE system.schema_columnfamilies SET column_aliases 
> ='["column1","column2"]' WHERE keyspace_name = 'ks1' AND columnfamily_name = 
> 't1';
> Once you exit and restart cqlsh, DESCRIBE is not working as per C* 1.2
> cqlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1'}  AND durable_writes = true;
> CREATE TABLE ks1.t1 (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'sstable_size_in_mb': '32', 'class': 
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression': 
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.1
> AND speculative_retry = '99.0PERCENTILE';



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

[jira] [Updated] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process

[Michael Fong (JIRA)]

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

Michael Fong updated CASSANDRA-11748:
-
Priority: Critical  (was: Major)

> Schema version mismatch may leads to Casandra OOM at bootstrap during a 
> rolling upgrade process
> ---
>
> Key: CASSANDRA-11748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
> Project: Cassandra
>  Issue Type: Bug
> Environment: Rolling upgrade process from 1.2.19 to 2.0.17. 
> CentOS 6.6
>Reporter: Michael Fong
>Priority: Critical
>
> We have observed multiple times when a multi-node C* (v2.0.17) cluster ran 
> into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. 
> Here is the simple guideline of our rolling upgrade process
> 1. Update schema on a node, and wait until all nodes to be in schema version 
> agreemnt - via nodetool describeclulster
> 2. Restart a Cassandra node
> 3. After restart, there is a chance that the the restarted node has different 
> schema version.
> 4. All nodes in cluster start to rapidly exchange schema information, and any 
> of node could run into OOM. 
> The following is the system.log that occur in one of our 2-node cluster test 
> bed
> --
> Before rebooting node 2:
> Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> After rebooting node 2, 
> Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) 
> Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b
> The node2  keeps submitting the migration task over 100+ times to the other 
> node.
> INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node 
> /192.168.88.33 has restarted, now UP
> INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) 
> Updating topology for /192.168.88.33
> ...
> DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line 
> 102) Submitting migration task for /192.168.88.33
> ... ( over 100+ times)
> --
> On the otherhand, Node 1 keeps updating its gossip information, followed by 
> receiving and submitting migrationTask afterwards: 
> INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line 
> 978) InetAddress /192.168.88.34 is now UP
> ...
> DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 
> MigrationRequestVerbHandler.java (line 41) Received migration request from 
> /192.168.88.34.
> …… ( over 100+ times)
> DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line 
> 127) submitting migration task for /192.168.88.34
> .  (over 50+ times)
> On the side note, we have over 200+ column families defined in Cassandra 
> database, which may related to this amount of rpc traffic.



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

[jira] [Updated] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process

[Michael Fong (JIRA)]

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

Michael Fong updated CASSANDRA-11748:
-
Environment: 
Rolling upgrade process from 1.2.19 to 2.0.17. 
CentOS 6.6
Occurred in different C* node of different scale of deployment (2G ~ 5G)

  was:
Rolling upgrade process from 1.2.19 to 2.0.17. 
CentOS 6.6


> Schema version mismatch may leads to Casandra OOM at bootstrap during a 
> rolling upgrade process
> ---
>
> Key: CASSANDRA-11748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
> Project: Cassandra
>  Issue Type: Bug
> Environment: Rolling upgrade process from 1.2.19 to 2.0.17. 
> CentOS 6.6
> Occurred in different C* node of different scale of deployment (2G ~ 5G)
>Reporter: Michael Fong
>Priority: Critical
>
> We have observed multiple times when a multi-node C* (v2.0.17) cluster ran 
> into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. 
> Here is the simple guideline of our rolling upgrade process
> 1. Update schema on a node, and wait until all nodes to be in schema version 
> agreemnt - via nodetool describeclulster
> 2. Restart a Cassandra node
> 3. After restart, there is a chance that the the restarted node has different 
> schema version.
> 4. All nodes in cluster start to rapidly exchange schema information, and any 
> of node could run into OOM. 
> The following is the system.log that occur in one of our 2-node cluster test 
> bed
> --
> Before rebooting node 2:
> Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> After rebooting node 2, 
> Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) 
> Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b
> The node2  keeps submitting the migration task over 100+ times to the other 
> node.
> INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node 
> /192.168.88.33 has restarted, now UP
> INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) 
> Updating topology for /192.168.88.33
> ...
> DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line 
> 102) Submitting migration task for /192.168.88.33
> ... ( over 100+ times)
> --
> On the otherhand, Node 1 keeps updating its gossip information, followed by 
> receiving and submitting migrationTask afterwards: 
> INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line 
> 978) InetAddress /192.168.88.34 is now UP
> ...
> DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 
> MigrationRequestVerbHandler.java (line 41) Received migration request from 
> /192.168.88.34.
> …… ( over 100+ times)
> DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line 
> 127) submitting migration task for /192.168.88.34
> .  (over 50+ times)
> On the side note, we have over 200+ column families defined in Cassandra 
> database, which may related to this amount of rpc traffic.



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

[jira] [Commented] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process

[Michael Fong (JIRA)]

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

Michael Fong commented on CASSANDRA-11748:
--

The reason of why schema version would change after restart is yet unknown. 
However, having different schema version and leading to flood Cassandra heap 
space seems pretty easy to reproduce. 
All we have tried to do is
1. To block gossip communication between a 2-node cluster via iptables
2. Keep updating schema on a node and so schema version is different
3. Unblock the firewall setting
4. We would see the message storm on exchanging schema information, and 
Cassandra would possibly run into OOM if it is small heap size.

P.S. It seems somewhat related to the number of schema change; the more the 
change, the greater the scale of message exchange.

> Schema version mismatch may leads to Casandra OOM at bootstrap during a 
> rolling upgrade process
> ---
>
> Key: CASSANDRA-11748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
> Project: Cassandra
>  Issue Type: Bug
> Environment: Rolling upgrade process from 1.2.19 to 2.0.17. 
> CentOS 6.6
>Reporter: Michael Fong
>
> We have observed multiple times when a multi-node C* (v2.0.17) cluster ran 
> into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. 
> Here is the simple guideline of our rolling upgrade process
> 1. Update schema on a node, and wait until all nodes to be in schema version 
> agreemnt - via nodetool describeclulster
> 2. Restart a Cassandra node
> 3. After restart, there is a chance that the the restarted node has different 
> schema version.
> 4. All nodes in cluster start to rapidly exchange schema information, and any 
> of node could run into OOM. 
> The following is the system.log that occur in one of our 2-node cluster test 
> bed
> --
> Before rebooting node 2:
> Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> After rebooting node 2, 
> Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) 
> Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b
> The node2  keeps submitting the migration task over 100+ times to the other 
> node.
> INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node 
> /192.168.88.33 has restarted, now UP
> INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) 
> Updating topology for /192.168.88.33
> ...
> DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line 
> 102) Submitting migration task for /192.168.88.33
> ... ( over 100+ times)
> --
> On the otherhand, Node 1 keeps updating its gossip information, followed by 
> receiving and submitting migrationTask afterwards: 
> INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line 
> 978) InetAddress /192.168.88.34 is now UP
> ...
> DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 
> MigrationRequestVerbHandler.java (line 41) Received migration request from 
> /192.168.88.34.
> …… ( over 100+ times)
> DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line 
> 127) submitting migration task for /192.168.88.34
> .  (over 50+ times)
> On the side note, we have over 200+ column families defined in Cassandra 
> database, which may related to this amount of rpc traffic.



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

[jira] [Updated] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process

[Michael Fong (JIRA)]

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

Michael Fong updated CASSANDRA-11748:
-
Since Version: 2.0.17

> Schema version mismatch may leads to Casandra OOM at bootstrap during a 
> rolling upgrade process
> ---
>
> Key: CASSANDRA-11748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
> Project: Cassandra
>  Issue Type: Bug
> Environment: Rolling upgrade process from 1.2.19 to 2.0.17. 
> CentOS 6.6
>Reporter: Michael Fong
>
> We have observed multiple times when a multi-node C* (v2.0.17) cluster ran 
> into OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. 
> Here is the simple guideline of our rolling upgrade process
> 1. Update schema on a node, and wait until all nodes to be in schema version 
> agreemnt - via nodetool describeclulster
> 2. Restart a Cassandra node
> 3. After restart, there is a chance that the the restarted node has different 
> schema version.
> 4. All nodes in cluster start to rapidly exchange schema information, and any 
> of node could run into OOM. 
> The following is the system.log that occur in one of our 2-node cluster test 
> bed
> --
> Before rebooting node 2:
> Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 
> MigrationManager.java (line 328) Gossiping my schema version 
> 4cb463f8-5376-3baf-8e88-a5cc6a94f58f
> After rebooting node 2, 
> Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) 
> Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b
> The node2  keeps submitting the migration task over 100+ times to the other 
> node.
> INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node 
> /192.168.88.33 has restarted, now UP
> INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) 
> Updating topology for /192.168.88.33
> ...
> DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line 
> 102) Submitting migration task for /192.168.88.33
> ... ( over 100+ times)
> --
> On the otherhand, Node 1 keeps updating its gossip information, followed by 
> receiving and submitting migrationTask afterwards: 
> INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line 
> 978) InetAddress /192.168.88.34 is now UP
> ...
> DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 
> MigrationRequestVerbHandler.java (line 41) Received migration request from 
> /192.168.88.34.
> …… ( over 100+ times)
> DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line 
> 127) submitting migration task for /192.168.88.34
> .  (over 50+ times)
> On the side note, we have over 200+ column families defined in Cassandra 
> database, which may related to this amount of rpc traffic.



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

[jira] [Created] (CASSANDRA-11748) Schema version mismatch may leads to Casandra OOM at bootstrap during a rolling upgrade process

[Michael Fong (JIRA)]

Michael Fong created CASSANDRA-11748:


 Summary: Schema version mismatch may leads to Casandra OOM at 
bootstrap during a rolling upgrade process
 Key: CASSANDRA-11748
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11748
 Project: Cassandra
  Issue Type: Bug
 Environment: Rolling upgrade process from 1.2.19 to 2.0.17. 
CentOS 6.6
Reporter: Michael Fong


We have observed multiple times when a multi-node C* (v2.0.17) cluster ran into 
OOM in bootstrap during a rolling upgrade process from 1.2.19 to 2.0.17. 

Here is the simple guideline of our rolling upgrade process
1. Update schema on a node, and wait until all nodes to be in schema version 
agreemnt - via nodetool describeclulster
2. Restart a Cassandra node
3. After restart, there is a chance that the the restarted node has different 
schema version.
4. All nodes in cluster start to rapidly exchange schema information, and any 
of node could run into OOM. 

The following is the system.log that occur in one of our 2-node cluster test bed
--
Before rebooting node 2:
Node 1: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,326 MigrationManager.java 
(line 328) Gossiping my schema version 4cb463f8-5376-3baf-8e88-a5cc6a94f58f

Node 2: DEBUG [MigrationStage:1] 2016-04-19 11:09:42,122 MigrationManager.java 
(line 328) Gossiping my schema version 4cb463f8-5376-3baf-8e88-a5cc6a94f58f

After rebooting node 2, 
Node 2: DEBUG [main] 2016-04-19 11:18:18,016 MigrationManager.java (line 328) 
Gossiping my schema version f5270873-ba1f-39c7-ab2e-a86db868b09b

The node2  keeps submitting the migration task over 100+ times to the other 
node.
INFO [GossipStage:1] 2016-04-19 11:18:18,261 Gossiper.java (line 1011) Node 
/192.168.88.33 has restarted, now UP
INFO [GossipStage:1] 2016-04-19 11:18:18,262 TokenMetadata.java (line 414) 
Updating topology for /192.168.88.33
...
DEBUG [GossipStage:1] 2016-04-19 11:18:18,265 MigrationManager.java (line 102) 
Submitting migration task for /192.168.88.33
... ( over 100+ times)
--
On the otherhand, Node 1 keeps updating its gossip information, followed by 
receiving and submitting migrationTask afterwards: 

INFO [RequestResponseStage:3] 2016-04-19 11:18:18,333 Gossiper.java (line 978) 
InetAddress /192.168.88.34 is now UP
...
DEBUG [MigrationStage:1] 2016-04-19 11:18:18,496 
MigrationRequestVerbHandler.java (line 41) Received migration request from 
/192.168.88.34.
…… ( over 100+ times)
DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line 
127) submitting migration task for /192.168.88.34
.  (over 50+ times)

On the side note, we have over 200+ column families defined in Cassandra 
database, which may related to this amount of rpc traffic.




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

[jira] [Commented] (CASSANDRA-11746) Add per partition rate limiting

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-11746:


We implement something like this at the client / driver level, but how would 
you attempt to express it? yaml level per node ? Per table via DDL ? 

> Add per partition rate limiting
> ---
>
> Key: CASSANDRA-11746
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11746
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Richard Low
>
> In a similar spirit to the tombstone fail threshold, Cassandra could protect 
> itself against rogue clients issuing too many requests to the same partition 
> by rate limiting. Nodes could keep a sliding window of requests per partition 
> and immediately reject requests if the threshold has been reached. This could 
> stop hotspots from taking down a replica set.



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

[jira] [Commented] (CASSANDRA-10819) Generic Java UDF types

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10819:
-

Is this fixed? Trying the following example from 
[here|http://www.doanduyhai.com/blog/?p=1876]:
{noformat}
CREATE OR REPLACE FUNCTION cumulateCounter(state map, category 
text, count counter)
RETURNS NULL ON NULL INPUT
RETURNS map
LANGUAGE java
AS '
if(state.containsKey(category)) {
  state.put(category, state.get(category) + count); 
} else {
  state.put(category, count);
}
return state;
'; 
{noformat}

On trunk still gives:
{noformat}
InvalidRequest: code=2200 [Invalid query] message="Could not compile function 
'bla.cumulatecounter' from Java source: 
org.apache.cassandra.exceptions.InvalidRequestException: Java source 
compilation failed:
Line 3: The operator + is undefined for the argument type(s) Object, long
Line 5: Type safety: The method put(Object, Object) belongs to the raw type 
Map. References to generic type Map should be parameterized
Line 7: Type safety: The expression of type Map needs unchecked conversion to 
conform to Map
{noformat}


> Generic Java UDF types
> --
>
> Key: CASSANDRA-10819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10819
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
>  Labels: UDF, doc-impacting
> Fix For: 3.4
>
>
> At the moment we only generate raw type signatures for Java UDF methods. E.g. 
> a CQL argument type {{map}} is just mapped to {{java.util.Map}} 
> but could be mapped to {{java.util.Map}}.
> It's a probably simple but nice improvement and feels to be a LHF.
> Depending on the complexity it might be doable for 3.0.x, too.
> Thanks for the heads-up, [~doanduyhai]!



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

[jira] [Assigned] (CASSANDRA-11055) C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no attribute 'replace'

[Stefania (JIRA)]

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

Stefania reassigned CASSANDRA-11055:


Assignee: Stefania

> C*2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns 'NoneType' object has no 
> attribute 'replace'
> ---
>
> Key: CASSANDRA-11055
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11055
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.x
>
>
> C* 2.1 cqlsh DESCRIBE KEYSPACE ( or TABLE ) returns:
>  'NoneType' object has no attribute 'replace' 
> for thrift CF's originally created in C* 1.2.
> Repro:
> 1. Create cf in cassandra-cli on C* 1.2.x  (1.2.9 was used here)
> [default@ks1] CREATE COLUMN FAMILY t1
> ...   WITH column_type='Standard'
> ...   AND 
> comparator='CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type)'
> ...   AND default_validation_class='UTF8Type'
> ...   AND key_validation_class='UTF8Type'
> ...   AND read_repair_chance=0.1
> ...   AND dclocal_read_repair_chance=0.0
> ...   AND gc_grace=864000
> ...   AND min_compaction_threshold=4
> ...   AND max_compaction_threshold=32
> ...   AND replicate_on_write=true
> ...   AND compaction_strategy='LeveledCompactionStrategy' AND 
> compaction_strategy_options={sstable_size_in_mb: 32}
> ...   AND caching='KEYS_ONLY'
> ...   AND compression_options={sstable_compression:SnappyCompressor, 
> chunk_length_kb:64};
> qlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {
>   'class': 'NetworkTopologyStrategy',
>   'datacenter1': '1'
> };
> USE ks1;
> CREATE TABLE t1 (
>   key text,
>   column1 text,
>   column2 text,
>   value text,
>   PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=0.10 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.00 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.10 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '32', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '64', 'sstable_compression': 
> 'SnappyCompressor'};
> cqlsh> select keyspace_name, columnfamily_name,column_aliases,key_aliases 
> from system.schema_columnfamilies where keyspace_name= 'ks1';
>  keyspace_name | columnfamily_name | column_aliases | key_aliases
> ---+---++-
>ks1 |t1 | [] |  []
> 2/ Upgrade -> C* 2.0.9 -> nodetool upgradesstables -a
> At this stage , DESCRIBE in cqlsh is working
> 3/ Upgrade -> C* 2.1.12 -> nodetool upgradesstables -a
> DESCRIBE now fails:
> cqlsh> describe table ks1.t1;
> 'NoneType' object has no attribute 'replace'
> cqlsh> describe keyspace ks1;
> 'NoneType' object has no attribute 'replace'
> You can workaround by manually updating system.schema_columnfamilies
>  UPDATE system.schema_columnfamilies SET column_aliases 
> ='["column1","column2"]' WHERE keyspace_name = 'ks1' AND columnfamily_name = 
> 't1';
> Once you exit and restart cqlsh, DESCRIBE is not working as per C* 1.2
> cqlsh> describe keyspace ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1'}  AND durable_writes = true;
> CREATE TABLE ks1.t1 (
> key text,
> column1 text,
> column2 text,
> value text,
> PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (column1 ASC, column2 ASC)
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'sstable_size_in_mb': '32', 'class': 
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_kb': '64', 'sstable_compression': 
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.1
> AND speculative_retry = '99.0PERCENTILE';



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

[jira] [Created] (CASSANDRA-11747) Port CASSANDRA-10795 to C* 2.1, 2.2 to improve FailureDetector "unknown endpoint" message

[Erick Ramirez (JIRA)]

Erick Ramirez created CASSANDRA-11747:
-

 Summary: Port CASSANDRA-10795 to C* 2.1, 2.2 to improve 
FailureDetector "unknown endpoint" message
 Key: CASSANDRA-11747
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11747
 Project: Cassandra
  Issue Type: Improvement
Reporter: Erick Ramirez


When FailureDetector is called to check an IP which is no longer part of the 
cluster, the error message is unhelpful:

{noformat}
FailureDetector.java:223 - unknown endpoint /10.1.2.3
{noformat}

We should print additional information to make it easier for users to determine 
where in the stack the "unknown IP" is coming from.



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

[jira] [Created] (CASSANDRA-11746) Add per partition rate limiting

[Richard Low (JIRA)]

Richard Low created CASSANDRA-11746:
---

 Summary: Add per partition rate limiting
 Key: CASSANDRA-11746
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11746
 Project: Cassandra
  Issue Type: Improvement
Reporter: Richard Low


In a similar spirit to the tombstone fail threshold, Cassandra could protect 
itself against rogue clients issuing too many requests to the same partition by 
rate limiting. Nodes could keep a sliding window of requests per partition and 
immediately reject requests if the threshold has been reached. This could stop 
hotspots from taking down a replica set.



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

[jira] [Created] (CASSANDRA-11745) Add bytes limit to queries and paging

[Richard Low (JIRA)]

Richard Low created CASSANDRA-11745:
---

 Summary: Add bytes limit to queries and paging
 Key: CASSANDRA-11745
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11745
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Richard Low


For some data models, values may be of very different sizes. When querying 
data, limit by count doesn’t work well and leads to timeouts. It would be much 
better to limit by size of the response, probably by stopping at the first row 
that goes above the limit. This applies to paging too so you can safely page 
through such data without timeout worries.



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

[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11345:


My bad, and yes, it seems possible from the code.

> Assertion Errors "Memory was freed" during streaming
> 
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a 
> repair :
> On node /172.16.63.41
> {noformat}
> INFO  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Session with /10.174.216.160 is complete  
>   
> WARN  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Stream failed   
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>   
>
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>   
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>  
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
> 
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:331)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
>   
>
> {noformat} 
> On node /10.174.216.160
>  
> {noformat}   
> ERROR [STREAM-OUT-/172.16.63.41] 2016-03-09 02:38:14,140 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred  
> java.io.IOException: Connection reset by peer 
>   
>
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.7.0_65] 
>   
>
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[na:1.7.0_65] 
>   
>
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) 
> ~[na:1.7.0_65]

[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11345:
-

[~yukim] the "memory freed" problem happens on Node A, so obsoleting compaction 
happens on node A while it's streaming. Is this possible?

> Assertion Errors "Memory was freed" during streaming
> 
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a 
> repair :
> On node /172.16.63.41
> {noformat}
> INFO  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Session with /10.174.216.160 is complete  
>   
> WARN  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Stream failed   
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>   
>
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>   
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>  
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
> 
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:331)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
>   
>
> {noformat} 
> On node /10.174.216.160
>  
> {noformat}   
> ERROR [STREAM-OUT-/172.16.63.41] 2016-03-09 02:38:14,140 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred  
> java.io.IOException: Connection reset by peer 
>   
>
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.7.0_65] 
>   
>
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[na:1.7.0_65] 
>   
>
> at 

[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11345:


SSTable X in node B  is added (activated) when streaming all SSTables in the 
same table finishes.
So I guess compaction of SSTable X shouldn't be happening during streaming.

> Assertion Errors "Memory was freed" during streaming
> 
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a 
> repair :
> On node /172.16.63.41
> {noformat}
> INFO  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Session with /10.174.216.160 is complete  
>   
> WARN  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Stream failed   
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>   
>
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>   
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>  
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
> 
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:331)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
>   
>
> {noformat} 
> On node /10.174.216.160
>  
> {noformat}   
> ERROR [STREAM-OUT-/172.16.63.41] 2016-03-09 02:38:14,140 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred  
> java.io.IOException: Connection reset by peer 
>   
>
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.7.0_65] 
>   
>
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.7.0_65]
>   
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[na:1.7.0_65] 
>   
>
> at 

[jira] [Commented] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-11705:
-

fixed, and started ci

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Comment Edited] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Blake Eggleston (JIRA)]

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

Blake Eggleston edited comment on CASSANDRA-11705 at 5/10/16 9:37 PM:
--

| *3.0* | *3.7* | *trunk* |
| [branch|https://github.com/bdeggleston/cassandra/tree/11705-3.0] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-3.7] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-trunk] |
| 
[dtest|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-3.0-dtest/2/]
 | 
[dtest|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-3.7-dtest/2/]
 | 
[dtest|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-trunk-dtest/2/]
 |
| 
[testall|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-3.0-testall/2/]
 | 
[testall|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-3.7-testall/2/]
 | 
[testall|http://cassci.datastax.com/view/Dev/view/bdeggleston/job/bdeggleston-11705-trunk-testall/2/]
 |


was (Author: bdeggleston):
| *3.0* | *3.7* | *trunk* |
| [branch|https://github.com/bdeggleston/cassandra/tree/11705-3.0] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-3.7] | 
[branch|https://github.com/bdeggleston/cassandra/tree/11705-trunk] |

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11345:
-

[~vineus] What compaction strategy are you using? what is the average sstable 
size in the sending node?

I suspect the following race is happening:
- Node A sends SSTable X to bootstrapping node B
- SSTable X is obsoleted by compaction during streaming
- Node A finishes sending SSTable X to B and starts [calculating header 
size|https://github.com/apache/cassandra/blob/21448c50891642f95097a9e5ed0a3802bd90a877/src/java/org/apache/cassandra/streaming/StreamSession.java#L563]
 to update metrics (this became more expensive for compressed tables after 
CASSANDRA-10680)
- Meanwhile, node B finishes receiving SSTable X and sends "received" message 
to node A
- Node A receives "received" message for SSTable X and [releases its 
reference|https://github.com/apache/cassandra/blob/21448c50891642f95097a9e5ed0a3802bd90a877/src/java/org/apache/cassandra/streaming/messages/OutgoingFileMessage.java#L99],
 causing it to be garbage collected since it was obsoleted
- Since {{CompressionMetadata}} was released, [header size 
calculation|https://github.com/apache/cassandra/blob/21448c50891642f95097a9e5ed0a3802bd90a877/src/java/org/apache/cassandra/streaming/messages/FileMessageHeader.java#L133]
 fails with {{Memory was freed}}

Do you think this is plausible [~yukim] ? 

Simple solution would be to cache header size on first calculation, but we need 
to confirm first this is really what is happening because it could be hiding 
some other issue.

[~vineus] Can you [set log 
level|https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSetLogLev.html]
 of package {{org.apache.cassandra.streaming}} on sending on receiving nodes 
and attach system logs after error happens again?

> Assertion Errors "Memory was freed" during streaming
> 
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a 
> repair :
> On node /172.16.63.41
> {noformat}
> INFO  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Session with /10.174.216.160 is complete  
>   
> WARN  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Stream failed   
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>   
>
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>   
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>  
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
> 
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at 
> 

[jira] [Commented] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11309:
-

This seems like a bug fix (rather than an improvement) to me, so I would commit 
it to 2.2+.

> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
> 
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is 
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}). 
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but 
> work as expected for CALLED ON NULL INPUT.



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

[jira] [Assigned] (CASSANDRA-11740) Nodes have wrong membership view of the cluster

[Joel Knighton (JIRA)]

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

Joel Knighton reassigned CASSANDRA-11740:
-

Assignee: Joel Knighton

> Nodes have wrong membership view of the cluster
> ---
>
> Key: CASSANDRA-11740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11740
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster.
> The problem we found is that there are some nodes (>10) have very wrong view 
> of the cluster.
> For example, we have 3 data centers A, B and C. On the problem nodes, in the 
> output of the 'nodetool status', it shows that ~100 nodes are not in data 
> center A, B, or C. Instead, it shows nodes are in DC1, and rack r1, which is 
> very wrong. And as a result, the node will return wrong results to client 
> requests.
> Datacenter: DC1
> ===
> Status=Up/Down
> / State=Normal/Leaving/Joining/Moving
> – Address Load Tokens Owns Host ID Rack
> UN 2401:db00:11:6134:face:0:1:0 509.52 GB 256 ? 
> e24656ac-c3b2-4117-b933-a5b06852c993 r1
> UN 2401:db00:11:b218:face:0:5:0 510.01 GB 256 ? 
> 53da2104-b1b5-4fa5-a3dd-52c7557149f9 r1
> UN 2401:db00:2130:5133:face:0:4d:0 459.75 GB 256 ? 
> ef8311f0-f6b8-491c-904d-baa925cdd7c2 r1
> We are using GossipingPropertyFileSnitch.
> Thanks



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

[jira] [Reopened] (CASSANDRA-11740) Nodes have wrong membership view of the cluster

[Joel Knighton (JIRA)]

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

Joel Knighton reopened CASSANDRA-11740:
---

> Nodes have wrong membership view of the cluster
> ---
>
> Key: CASSANDRA-11740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11740
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster.
> The problem we found is that there are some nodes (>10) have very wrong view 
> of the cluster.
> For example, we have 3 data centers A, B and C. On the problem nodes, in the 
> output of the 'nodetool status', it shows that ~100 nodes are not in data 
> center A, B, or C. Instead, it shows nodes are in DC1, and rack r1, which is 
> very wrong. And as a result, the node will return wrong results to client 
> requests.
> Datacenter: DC1
> ===
> Status=Up/Down
> / State=Normal/Leaving/Joining/Moving
> – Address Load Tokens Owns Host ID Rack
> UN 2401:db00:11:6134:face:0:1:0 509.52 GB 256 ? 
> e24656ac-c3b2-4117-b933-a5b06852c993 r1
> UN 2401:db00:11:b218:face:0:5:0 510.01 GB 256 ? 
> 53da2104-b1b5-4fa5-a3dd-52c7557149f9 r1
> UN 2401:db00:2130:5133:face:0:4d:0 459.75 GB 256 ? 
> ef8311f0-f6b8-491c-904d-baa925cdd7c2 r1
> We are using GossipingPropertyFileSnitch.
> Thanks



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

[jira] [Commented] (CASSANDRA-11645) (single) dtest failure in snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11645:


no repros in bulk run. closing this.

> (single) dtest failure in 
> snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog
> -
>
> Key: CASSANDRA-11645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11645
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> This was a singular but pretty recent failure, so thought it might be worth 
> digging into to see if it repros.
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/211/testReport/snapshot_test/TestArchiveCommitlog/test_archive_commitlog_with_active_commitlog
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #211



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

[jira] [Comment Edited] (CASSANDRA-11709) Lock contention when large number of dead nodes come back within short time

[Joel Knighton (JIRA)]

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

Joel Knighton edited comment on CASSANDRA-11709 at 5/10/16 8:38 PM:


EDIT: My previous conjecture here was incorrect. I see now that 
{{TokenMetadata.updateNormalTokens}} as called in {{handleStateNormal}} will 
invalidate the cached ring. 

We invalidate this cached ring for every node who has reenabled gossip because 
this causes a generation change, so we go through {{updateNormalTokens}}. I am 
investigating mitigation strategies here.

I've reopened the issue I previously closed as duplicate - although I believe 
it was also a consequence of disable/enable of gossip, I no longer believe it 
is as closely related as I thought.


was (Author: jkni):
Sorry [~dikanggu] - looking at this further, I believe that [CASSANDRA-11740] 
is actually the root cause of this issue, so I've resolved it as a duplicate 
and we can continue here.

I do not believe this is related to the pending gossip tasks - I believe that 
the actual root cause is the change in datacenter/rack you mentioned. The 
GossipingPropertyFileSnitch periodically reloads its configuration and 
invalidates the cached token ring if datacenter/rack has changed. If you didn't 
bootstrap/decommission any nodes during your testing, I suspect this is the 
root cause of the invalidations.

The following information will help resolve this issue:
- What version of Cassandra are you running?
- Have you always been using GossipingPropertyFileSnitch?
- Is this an issue you've only seen once or is it reproducible?
- Did you make any changes to cassandra-rackdc.properties files during the 
test? How are you make changes to your cassandra-rackdc.properties files?
- Can you attach a cassandra-rackdc.properties file from an affected node?
- Can you attach a log from an affected node? In addition, if you have it, can 
you attach the full jstack from an affected node?

In all the above questions, "affected node" refers to a node where many 
read/write threads are blocked on the cachedOnlyTokenMap.

Thanks.

> Lock contention when large number of dead nodes come back within short time
> ---
>
> Key: CASSANDRA-11709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11709
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster. 
> We were trying to simulate a data center failure, by disabling the gossip on 
> all the nodes in one data center. After ~20mins, I re-enabled the gossip on 
> those nodes, was doing 5 nodes in each batch, and sleep 5 seconds between the 
> batch.
> After that, I saw the latency of read/write requests increased a lot, and 
> client requests started to timeout.
> On the node, I can see there are huge number of pending tasks in GossipStage. 
> =
> 2016-05-02_23:55:08.99515 WARN  23:55:08 Gossip stage has 36337 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:09.36009 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:41:0 state jump to normal
> 2016-05-02_23:55:09.99057 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:43:0 state jump to normal
> 2016-05-02_23:55:10.09742 WARN  23:55:10 Gossip stage has 36421 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:10.91860 INFO  23:55:10 Node 
> /2401:db00:2020:717a:face:0:45:0 state jump to normal
> 2016-05-02_23:55:11.20100 WARN  23:55:11 Gossip stage has 36558 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:11.57893 INFO  23:55:11 Node 
> /2401:db00:2030:612a:face:0:49:0 state jump to normal
> 2016-05-02_23:55:12.23405 INFO  23:55:12 Node /2401:db00:2020:7189:face:0:7:0 
> state jump to normal
> 
> And I took jstack of the node, I found the read/write threads are blocked by 
> a lock,
>  read thread ==
> "Thrift:7994" daemon prio=10 tid=0x7fde91080800 nid=0x5255 waiting for 
> monitor entry [0x7fde6f8a1000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
> - waiting to lock <0x7fe4faef4398> (a 
> org.apache.cassandra.locator.TokenMetadata)
> at 
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
> at 
> org.apache.cassandra.service.StorageService.getLiveNaturalEndpoints(StorageService.java:3155)
> at 
> 

[jira] [Commented] (CASSANDRA-11269) Improve UDF compilation error messages

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11269:
--

Shall I commit this to 3.7?

> Improve UDF compilation error messages
> --
>
> Key: CASSANDRA-11269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11269
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> When UDF exception fails, the error message will just mention the top-level 
> exception and none of the causes. This is fine for usual compilation errors 
> but makes it essentially very difficult to identify the root cause.
> So, this ticket's about to improve the error messages at the end of the 
> constructor of {{JavaBasedUDFunction}}.



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

[jira] [Resolved] (CASSANDRA-11645) (single) dtest failure in snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog

[Russ Hatch (JIRA)]

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

Russ Hatch resolved CASSANDRA-11645.

Resolution: Cannot Reproduce

> (single) dtest failure in 
> snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog
> -
>
> Key: CASSANDRA-11645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11645
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> This was a singular but pretty recent failure, so thought it might be worth 
> digging into to see if it repros.
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/211/testReport/snapshot_test/TestArchiveCommitlog/test_archive_commitlog_with_active_commitlog
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #211



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

[jira] [Commented] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11309:
--

Shall I commit this to 3.7?

> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
> 
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is 
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}). 
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but 
> work as expected for CALLED ON NULL INPUT.



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

[jira] [Updated] (CASSANDRA-11668) InterruptedException in HintsDispatcher

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11668:
---
Description: 
This exception was seen when trying to repro a test problem. The original issue 
test problem appears to be a non-issue, but the exception seems like it could 
be worth investigation.

This happened on upgrade from 3.2.1 to 3.3 HEAD (a soon to be retired 
test-case).

The test does a rolling upgrade where nodes are one by one stopped, upgraded, 
and started on the new version.

The exception occurred some time after starting node1 on the upgraded version, 
and upgrading/starting node2 on the new version. Node2 logged the exception.
{noformat}
node2: ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 
CassandraDaemon.java:195 - Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.AssertionError: java.lang.InterruptedException
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.lang.InterruptedException: null
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUntil(WaitQueue.java:301)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.utils.concurrent.SimpleCondition.await(SimpleCondition.java:63)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:201)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
... 11 common frames omitted
Unexpected error in node2 log, error: 
ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 CassandraDaemon.java:195 - 
Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.AssertionError: java.lang.InterruptedException
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.lang.InterruptedException: null
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 

[jira] [Commented] (CASSANDRA-11668) InterruptedException in HintsDispatcher

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11668:


The InterruptedException occurred only once in 100 test runs, so chances of 
repro are slim. If this is just a routine problem due to inconvenient timing in 
the test, perhaps (as suggested by [~philipthompson] ) the log level could be 
reduced.

> InterruptedException in HintsDispatcher
> ---
>
> Key: CASSANDRA-11668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11668
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> This exception was seen when trying to repro a test problem. The original 
> issue test problem appears to be a non-issue, but the exception seems like it 
> could be worth investigation.
> This happened on upgrade from 3.2.1 to 3.3 HEAD (a soon to be retired 
> test-case).
> The test does a rolling upgrade where nodes are one by one stopped, upgraded, 
> and started on the new version.
> The exception occurred some time after starting node1 on the upgraded 
> version, and upgrading/starting node2 on the new version. Node2 logged the 
> exception.
> {noformat}
> node2: ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 
> CassandraDaemon.java:195 - Exception in thread 
> Thread[HintsDispatcher:2,1,main]
> java.lang.AssertionError: java.lang.InterruptedException
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_51]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> Caused by: java.lang.InterruptedException: null
>   at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUntil(WaitQueue.java:301)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.utils.concurrent.SimpleCondition.await(SimpleCondition.java:63)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:201)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   ... 11 common frames omitted
> Unexpected error in node2 log, error: 
> ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 CassandraDaemon.java:195 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.AssertionError: java.lang.InterruptedException
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
>  

[jira] [Updated] (CASSANDRA-11668) InterruptedException in HintsDispatcher

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11668:
---
Issue Type: Bug  (was: Test)

> InterruptedException in HintsDispatcher
> ---
>
> Key: CASSANDRA-11668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11668
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> This exception was seen when trying to repro a test problem. The original 
> issue test problem appears to be a non-issue, but the exception seems like it 
> could be worth investigation.
> This happened on upgrade from 3.2.1 to 3.3 HEAD (a soon to be retired 
> test-case).
> The test does a rolling upgrade where nodes are one by one stopped, upgraded, 
> and started on the new version.
> The exception occurred some time after starting node1 on the upgraded 
> version, and upgrading/starting node2 on the new version. Node2 logged the 
> exception.
> {noformat}
> node2: ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 
> CassandraDaemon.java:195 - Exception in thread 
> Thread[HintsDispatcher:2,1,main]
> java.lang.AssertionError: java.lang.InterruptedException
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_51]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_51]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> Caused by: java.lang.InterruptedException: null
>   at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUntil(WaitQueue.java:301)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.utils.concurrent.SimpleCondition.await(SimpleCondition.java:63)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:201)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   ... 11 common frames omitted
> Unexpected error in node2 log, error: 
> ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 CassandraDaemon.java:195 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.AssertionError: java.lang.InterruptedException
>   at 
> org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
> ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
>  ~[apache-cassandra-3.2.1.jar:3.2.1]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_51]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_51]
>   at 
> 

[jira] [Updated] (CASSANDRA-11668) InterruptedException in HintsDispatcher

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11668:
---
Description: 
This exception was seen when trying to repro a test problem. The original issue 
test problem appears to be a non-issue, but the exception seems like it could 
be worth investigation.

This happened on upgrade from 3.2.1 to 3.3 HEAD (a soon to be retired 
test-case).

The test does a rolling upgrade where nodes are one by one stopped, upgraded, 
and started on the new version.

The exception occurred some time after starting node1 on the upgraded version, 
and upgrading/starting node2 on the new version. Node2 logged the exception.
{noformat}
node2: ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 
CassandraDaemon.java:195 - Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.AssertionError: java.lang.InterruptedException
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.lang.InterruptedException: null
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUntil(WaitQueue.java:301)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.utils.concurrent.SimpleCondition.await(SimpleCondition.java:63)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:201)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
... 11 common frames omitted
Unexpected error in node2 log, error: 
ERROR [HintsDispatcher:2] 2016-05-09 23:37:45,816 CassandraDaemon.java:195 - 
Exception in thread Thread[HintsDispatcher:2,1,main]
java.lang.AssertionError: java.lang.InterruptedException
at 
org.apache.cassandra.hints.HintsDispatcher$Callback.await(HintsDispatcher.java:205)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:146)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:121) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:93) 
~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:247)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
~[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.lang.InterruptedException: null
at 
org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.checkInterrupted(WaitQueue.java:313)
 ~[apache-cassandra-3.2.1.jar:3.2.1]
at 

[jira] [Updated] (CASSANDRA-11668) InterruptedException in HintsDispatcher

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11668:
---
Summary: InterruptedException in HintsDispatcher  (was: dtest failure in 
upgrade_tests.upgrade_through_versions_test.ProtoV4Upgrade_3_2_UpTo_3_3_HEAD.rolling_upgrade_with_internode_ssl_test)

> InterruptedException in HintsDispatcher
> ---
>
> Key: CASSANDRA-11668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11668
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> since this was on upgrade to 3.3 head, I doubt it's an actual problem 
> (assuming changes aren't actively happening there). Nevertheless, should take 
> a quick look and see if there's anything going on.
> example failure:
> http://cassci.datastax.com/job/upgrade_tests-all/39/testReport/upgrade_tests.upgrade_through_versions_test/ProtoV4Upgrade_3_2_UpTo_3_3_HEAD/rolling_upgrade_with_internode_ssl_test
> Failed on CassCI build upgrade_tests-all #39



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

[jira] [Created] (CASSANDRA-11744) Trying to restart a 2.2.5 node, nodetool disablethrift fails

[Peter Norton (JIRA)]

Peter Norton created CASSANDRA-11744:


 Summary: Trying to restart a 2.2.5 node, nodetool disablethrift 
fails
 Key: CASSANDRA-11744
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11744
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Norton
 Attachments: failure.jstack.out

We have a 2.2.5 cluster running in AWS VPC with EBS volumes.  Earlier today 3 
nodes seem to have gone into a bad state - clients were seeing high latencies 
when writing to these nodes, and the write to the commitlog on each of these 
nodes seemed high - more than the relatively low number of iops that AWS 
allocated to these volumes.  While trying to understand the situation we 
attempted to restart the 3 nodes.  We attempted to do a nodetool disablebinary; 
nodetool disablethrift; nodetool flush. and then stop the process.

When trying to disablethrift, the following stack trace appeared in the 
system.log:

```
INFO  [RMI TCP Connection(8)-172.26.32.248] 2016-05-10 15:26:58,599 
Server.java:218 - Stop listening for CQL clients
INFO  [RMI TCP Connection(10)-172.26.32.248] 2016-05-10 15:27:01,975 
ThriftServer.java:142 - Stop listening to thrift clients
ERROR [RPC-Thread:34] 2016-05-10 15:27:03,794 Message.java:324 - Unexpected 
throwable while invoking!
java.lang.NullPointerException: null
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83) 
~[thrift-server-0.3.7.jar:na]
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
 ~[thrift-server-0.3.7.jar:na]
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
 ~[thrift-server-0.3.7.jar:na]
at 
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156) 
~[libthrift-0.9.2.jar:0.9.2]
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55) 
~[libthrift-0.9.2.jar:0.9.2]
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
~[libthrift-0.9.2.jar:0.9.2]
at com.thinkaurelius.thrift.Message.invoke(Message.java:314) 
~[thrift-server-0.3.7.jar:na]
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90) 
[thrift-server-0.3.7.jar:na]
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
 [thrift-server-0.3.7.jar:na]
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
 [thrift-server-0.3.7.jar:na]
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112) 
[disruptor-3.0.1.jar:na]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
```

The attached jstack was taken from a node after the above was noticed.



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

[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Olivier Michallat (JIRA)]

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

Olivier Michallat updated CASSANDRA-10786:
--
Description: 
This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 
statement when the table is altered, to force clients to update their local 
copy of the metadata.

There's still an issue if multiple clients are connected to the same host. The 
first client to execute the query after the cache was invalidated will receive 
an UNPREPARED response, re-prepare, and update its local metadata. But other 
clients might miss it entirely (the MD5 hasn't changed), and they will keep 
using their old metadata. For example:
# {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA 
and clientB both have a cache of the metadata (columns b and c) locally
# column a gets added to the table, C* invalidates its cache entry
# clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
re-prepares on the fly and updates its local metadata to (a, b, c)
# prepared statement is now in C*’s cache again, with the same md5 abc123
# clientB sends an EXECUTE request for id abc123. Because the cache has been 
populated again, the query succeeds. But clientB still has not updated its 
metadata, it’s still (b,c)

One solution that was suggested is to include a hash of the result set metadata 
in the md5. This way the md5 would change at step 3, and any client using the 
old md5 would get an UNPREPARED, regardless of whether another client already 
reprepared.

  was:
This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 
statement when the table is altered, to force clients to update their local 
copy of the metadata.

There's still an issue if multiple clients are connected to the same host. The 
first client to execute the query after the cache was invalidated will receive 
an UNPREPARED response, re-prepare, and update its local metadata. But other 
clients might miss it entirely (the MD5 hasn't changed), and they will keep 
using their old metadata.

One solution that was suggested is to include a hash of the result set metadata 
in the prepared statement id. The old id would become invalid, forcing all 
clients to reprepare.


> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Commented] (CASSANDRA-11114) Document which type conversions are allowed

[Giampaolo (JIRA)]

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

Giampaolo commented on CASSANDRA-4:
---

About this issue, I wrote a little 
[program|https://github.com/giampaolotrapasso/cassandra-type-conversions] to 
test all possible combinations of type conversion in {{ALTER TABLE}} statement. 
I run this on 3.4, I will run again with the 3.5/3.6.

I've tried all basic types without considering when the column is a partition 
key or a clustering column. This is the list of the allowed conversion

||From|To||
|_timestamp_|_bigint_|
|ascii, bigint, boolean, _date_, decimal, double, float, inet, int, _smallint_, 
_text_, _time_, timestamp, timeuuid, _tinyint_, uuid, varchar, varint|blob|
|_int_|_date_|
|_bigint_|_time_|
|_ascii_, _varchar_|_text_|
|_bigint_|_timestamp_|
|_ascii_, _text_|_varchar_|
|_bigint_, _int_, _timestamp_|_varint_|
|timeuuid|uuid|

It differs a bit from what should be the most updated 
[documentation|https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cql_data_types_c.html].
 I have put in italic what are the additions respect to the mentioned url.

Going to do the same for clustering column, meanwhile any comment on this, if 
any, is appreciated.





> Document which type conversions are allowed
> ---
>
> Key: CASSANDRA-4
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL, Documentation and Website
>Reporter: Sylvain Lebresne
>Assignee: Giampaolo
>Priority: Minor
>  Labels: doc-impacting, lhf
>
> We allow only some type conversion through {{ALTER TABLE}} and type casts, 
> the ones that don't break stuff, but we don't currently document which ones 
> those are. We should add it to 
> http://cassandra.apache.org/doc/cql3/CQL-3.0.html.



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

[jira] [Assigned] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Alex Petrov (JIRA)]

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

Alex Petrov reassigned CASSANDRA-10786:
---

Assignee: Alex Petrov

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata.
> One solution that was suggested is to include a hash of the result set 
> metadata in the prepared statement id. The old id would become invalid, 
> forcing all clients to reprepare.



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

[jira] [Commented] (CASSANDRA-11470) dtest failure in materialized_views_test.TestMaterializedViews.base_replica_repair_test

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani commented on CASSANDRA-11470:
--

I am having the same exception triggered after a runtime exception thrown by 
the graphitereporter:

{{code:xml}}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-10 18:41:21,672 
ScheduledReporter.java:119 - RuntimeException thrown from 
GraphiteReporter#report. Exception was suppressed.
java.lang.RuntimeException: Failed to list files in 
/data/cassandra/data/schema_test/cf_test-e32122c0800c11e48a94fb3921529dd4
{{code}

> dtest failure in 
> materialized_views_test.TestMaterializedViews.base_replica_repair_test
> ---
>
> Key: CASSANDRA-11470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11470
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.6, 3.0.6
>
> Attachments: node1.log, node2.log, node2_debug.log, node3.log, 
> node3_debug.log
>
>
> base_replica_repair_test has failed on trunk with the following exception in 
> the log of node2:
> {code}
> ERROR [main] 2016-03-31 08:48:46,949 CassandraDaemon.java:708 - Exception 
> encountered during startup
> java.lang.RuntimeException: Failed to list files in 
> /mnt/tmp/dtest-du964e/test/node2/data0/system_schema/views-9786ac1cdd583201a7cdad556410c985
> at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:725)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Directories$SSTableLister.list(Directories.java:690) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:567)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:555)
>  ~[main/:na]
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:383) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:320) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:130) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:107) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:139)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepareRestrictions(SelectStatement.java:864)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:811)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:799)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:242)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:286)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:294)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.query(SchemaKeyspace.java:1246) 
> ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:875)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
>  ~[main/:na]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134) 
> ~[main/:na]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:562)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:691) 
> [main/:na]
> Caused by: java.lang.RuntimeException: Failed to list directory files in 
> /mnt/tmp/dtest-du964e/test/node2/data0/system_schema/views-9786ac1cdd583201a7cdad556410c985,
>  inconsistent disk state for transaction 
> [ma_txn_flush_58db56b0-f71d-11e5-bf68-03a01adb9f11.log in 
> /mnt/tmp/dtest-du964e/test/node2/data0/system_schema/views-9786ac1cdd583201a7cdad556410c985]
> at 
> 

[jira] [Comment Edited] (CASSANDRA-11470) dtest failure in materialized_views_test.TestMaterializedViews.base_replica_repair_test

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani edited comment on CASSANDRA-11470 at 5/10/16 6:44 PM:
---

I am having the same exception triggered after a runtime exception thrown by 
the graphitereporter:

{code:xml}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-10 18:41:21,672 
ScheduledReporter.java:119 - RuntimeException thrown from 
GraphiteReporter#report. Exception was suppressed.
java.lang.RuntimeException: Failed to list files in 
/data/cassandra/data/schema_test/cf_test-e32122c0800c11e48a94fb3921529dd4
{code}


was (Author: ostefano):
I am having the same exception triggered after a runtime exception thrown by 
the graphitereporter:

{{code:xml}}
ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-10 18:41:21,672 
ScheduledReporter.java:119 - RuntimeException thrown from 
GraphiteReporter#report. Exception was suppressed.
java.lang.RuntimeException: Failed to list files in 
/data/cassandra/data/schema_test/cf_test-e32122c0800c11e48a94fb3921529dd4
{{code}

> dtest failure in 
> materialized_views_test.TestMaterializedViews.base_replica_repair_test
> ---
>
> Key: CASSANDRA-11470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11470
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.6, 3.0.6
>
> Attachments: node1.log, node2.log, node2_debug.log, node3.log, 
> node3_debug.log
>
>
> base_replica_repair_test has failed on trunk with the following exception in 
> the log of node2:
> {code}
> ERROR [main] 2016-03-31 08:48:46,949 CassandraDaemon.java:708 - Exception 
> encountered during startup
> java.lang.RuntimeException: Failed to list files in 
> /mnt/tmp/dtest-du964e/test/node2/data0/system_schema/views-9786ac1cdd583201a7cdad556410c985
> at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:53)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:725)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.Directories$SSTableLister.list(Directories.java:690) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:567)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:555)
>  ~[main/:na]
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:383) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:320) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:130) 
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:107) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:139)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepareRestrictions(SelectStatement.java:864)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:811)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:799)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:242)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:286)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:294)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.query(SchemaKeyspace.java:1246) 
> ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:875)
>  ~[main/:na]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
>  ~[main/:na]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134) 
> ~[main/:na]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:562)
>  [main/:na]
> at 
> 

[jira] [Commented] (CASSANDRA-11709) Lock contention when large number of dead nodes come back within short time

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11709:
---

Sorry [~dikanggu] - looking at this further, I believe that [CASSANDRA-11740] 
is actually the root cause of this issue, so I've resolved it as a duplicate 
and we can continue here.

I do not believe this is related to the pending gossip tasks - I believe that 
the actual root cause is the change in datacenter/rack you mentioned. The 
GossipingPropertyFileSnitch periodically reloads its configuration and 
invalidates the cached token ring if datacenter/rack has changed. If you didn't 
bootstrap/decommission any nodes during your testing, I suspect this is the 
root cause of the invalidations.

The following information will help resolve this issue:
- What version of Cassandra are you running?
- Have you always been using GossipingPropertyFileSnitch?
- Is this an issue you've only seen once or is it reproducible?
- Did you make any changes to cassandra-rackdc.properties files during the 
test? How are you make changes to your cassandra-rackdc.properties files?
- Can you attach a cassandra-rackdc.properties file from an affected node?
- Can you attach a log from an affected node? In addition, if you have it, can 
you attach the full jstack from an affected node?

In all the above questions, "affected node" refers to a node where many 
read/write threads are blocked on the cachedOnlyTokenMap.

Thanks.

> Lock contention when large number of dead nodes come back within short time
> ---
>
> Key: CASSANDRA-11709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11709
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Joel Knighton
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster. 
> We were trying to simulate a data center failure, by disabling the gossip on 
> all the nodes in one data center. After ~20mins, I re-enabled the gossip on 
> those nodes, was doing 5 nodes in each batch, and sleep 5 seconds between the 
> batch.
> After that, I saw the latency of read/write requests increased a lot, and 
> client requests started to timeout.
> On the node, I can see there are huge number of pending tasks in GossipStage. 
> =
> 2016-05-02_23:55:08.99515 WARN  23:55:08 Gossip stage has 36337 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:09.36009 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:41:0 state jump to normal
> 2016-05-02_23:55:09.99057 INFO  23:55:09 Node 
> /2401:db00:2020:717a:face:0:43:0 state jump to normal
> 2016-05-02_23:55:10.09742 WARN  23:55:10 Gossip stage has 36421 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:10.91860 INFO  23:55:10 Node 
> /2401:db00:2020:717a:face:0:45:0 state jump to normal
> 2016-05-02_23:55:11.20100 WARN  23:55:11 Gossip stage has 36558 pending 
> tasks; skipping status check (no nodes will be marked down)
> 2016-05-02_23:55:11.57893 INFO  23:55:11 Node 
> /2401:db00:2030:612a:face:0:49:0 state jump to normal
> 2016-05-02_23:55:12.23405 INFO  23:55:12 Node /2401:db00:2020:7189:face:0:7:0 
> state jump to normal
> 
> And I took jstack of the node, I found the read/write threads are blocked by 
> a lock,
>  read thread ==
> "Thrift:7994" daemon prio=10 tid=0x7fde91080800 nid=0x5255 waiting for 
> monitor entry [0x7fde6f8a1000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at 
> org.apache.cassandra.locator.TokenMetadata.cachedOnlyTokenMap(TokenMetadata.java:546)
> - waiting to lock <0x7fe4faef4398> (a 
> org.apache.cassandra.locator.TokenMetadata)
> at 
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalEndpoints(AbstractReplicationStrategy.java:111)
> at 
> org.apache.cassandra.service.StorageService.getLiveNaturalEndpoints(StorageService.java:3155)
> at 
> org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1526)
> at 
> org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1521)
> at 
> org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:155)
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1328)
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1270)
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1195)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:118)

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.5 [deleted] 020dd2d10

[jira] [Updated] (CASSANDRA-11742) Failed bootstrap results in exception when node is restarted

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11742:

Reviewer: Joel Knighton

> Failed bootstrap results in exception when node is restarted
> 
>
> Key: CASSANDRA-11742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11742
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Minor
> Attachments: 11742.txt
>
>
> Since 2.2 a failed bootstrap results in a 
> {{org.apache.cassandra.exceptions.ConfigurationException: Found system 
> keyspace files, but they couldn't be loaded!}} exception when the node is 
> restarted. This did not happen in 2.1, it just tried to bootstrap again. I 
> know that the workaround is relatively easy, just delete the system keyspace 
> in the data folder on disk and try again, but its a bit annoying that you 
> have to do that.
> The problem seems to be that the creation of the {{system.local}} table has 
> been moved to just before the bootstrap begins (in 2.1 it was done much 
> earlier) and as a result its still in the memtable och commitlog if the 
> bootstrap failes. Still a few values is inserted to the {{system.local}} 
> table at an earlier point in the startup and they have been flushed from the 
> memtable to an sstable. When the node is restarted the 
> {{SystemKeyspace.checkHealth()}} is executed before the commitlog is replayed 
> and therefore only see the sstable with an incomplete {{system.local}} table 
> and throws an exception.
> I think we could fix this very easily by forceFlush the system keyspace in 
> the {{StorageServiceShutdownHook}}, I have included a patch that does this. 



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

[jira] [Updated] (CASSANDRA-11272) NullPointerException (NPE) during bootstrap startup in StorageService.java

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11272:

Reviewer: Joel Knighton

> NullPointerException (NPE) during bootstrap startup in StorageService.java
> --
>
> Key: CASSANDRA-11272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11272
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
> Environment: debian jesse up to date
>Reporter: Jason Kania
>Assignee: Alex Petrov
> Fix For: 2.2.x, 3.0.x, 3.7
>
>
> After bootstrapping fails due to stream closed error, the following error 
> results:
> {code}
> Feb 27, 2016 8:06:38 PM com.google.common.util.concurrent.ExecutionList 
> executeListener
> SEVERE: RuntimeException while executing runnable 
> com.google.common.util.concurrent.Futures$6@3d61813b with executor INSTANCE
> java.lang.NullPointerException
> at 
> org.apache.cassandra.service.StorageService$2.onFailure(StorageService.java:1284)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
> at 
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at 
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:210)
> at 
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:186)
> at 
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:430)
> at 
> org.apache.cassandra.streaming.StreamSession.onError(StreamSession.java:525)
> at 
> org.apache.cassandra.streaming.StreamSession.doRetry(StreamSession.java:645)
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:70)
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-9613:
-

It's supposed to be PA. Utests should already cover everything, just added one 
to verify object identity 

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



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

[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-9613:


[~snazy] is this supposed to be Patch Available, or do you still need to extend 
the patch?

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



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

[jira] [Commented] (CASSANDRA-11269) Improve UDF compilation error messages

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11269:
-

+1

> Improve UDF compilation error messages
> --
>
> Key: CASSANDRA-11269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11269
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> When UDF exception fails, the error message will just mention the top-level 
> exception and none of the causes. This is fine for usual compilation errors 
> but makes it essentially very difficult to identify the root cause.
> So, this ticket's about to improve the error messages at the end of the 
> constructor of {{JavaBasedUDFunction}}.



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

[jira] [Updated] (CASSANDRA-11269) Improve UDF compilation error messages

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11269:

Status: Ready to Commit  (was: Patch Available)

> Improve UDF compilation error messages
> --
>
> Key: CASSANDRA-11269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11269
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> When UDF exception fails, the error message will just mention the top-level 
> exception and none of the causes. This is fine for usual compilation errors 
> but makes it essentially very difficult to identify the root cause.
> So, this ticket's about to improve the error messages at the end of the 
> constructor of {{JavaBasedUDFunction}}.



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

[jira] [Commented] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11309:
-

+1

> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
> 
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is 
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}). 
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but 
> work as expected for CALLED ON NULL INPUT.



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

[jira] [Updated] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11309:

Status: Ready to Commit  (was: Patch Available)

> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
> 
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is 
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}). 
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but 
> work as expected for CALLED ON NULL INPUT.



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

[jira] [Commented] (CASSANDRA-11645) (single) dtest failure in snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11645:


bulk run here: 
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/96/

> (single) dtest failure in 
> snapshot_test.TestArchiveCommitlog.test_archive_commitlog_with_active_commitlog
> -
>
> Key: CASSANDRA-11645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11645
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> This was a singular but pretty recent failure, so thought it might be worth 
> digging into to see if it repros.
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/211/testReport/snapshot_test/TestArchiveCommitlog/test_archive_commitlog_with_active_commitlog
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #211



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

[jira] [Resolved] (CASSANDRA-11432) Counter values become under-counted when running repair.

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko resolved CASSANDRA-11432.
---
Resolution: Won't Fix

> Counter values become under-counted when running repair.
> 
>
> Key: CASSANDRA-11432
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11432
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Aleksey Yeschenko
>
> We are experimenting Counters in Cassandra 2.2.5. Our setup is that we have 6 
> nodes, across three different regions, and in each region, the replication 
> factor is 2. Basically, each nodes holds a full copy of the data.
> We are writing to cluster with CL = 2, and reading with CL = 1. 
> When are doing 30k/s counter increment/decrement per node, and at the 
> meanwhile, we are double writing to our mysql tier, so that we can measure 
> the accuracy of C* counter, compared to mysql.
> The experiment result was great at the beginning, the counter value in C* and 
> mysql are very close. The difference is less than 0.1%. 
> But when we start to run the repair on one node, the counter value in C* 
> become much less than the value in mysql,  the difference becomes larger than 
> 1%.
> My question is that is it a known problem that the counter value will become 
> under-counted if repair is running? Should we avoid running repair for 
> counter tables?
> Thanks. 



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

[jira] [Commented] (CASSANDRA-11432) Counter values become under-counted when running repair.

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11432:
---

You might be right, though I don't see it as a counters problem at this point 
(and there isn't much to be done here, either, so I'll be closing the ticket).

That said, some improvements that might help here eventually:
- CASSANDRA-10862, to reduce the number of referenced sstables during reads 
after streaming, will affect the read before write portion of counter writes
- CASSANDRA-9811, when implemented, will allow to eliminate some of the 
sstables on the read-before-write path, if any sstable X has its highest 
timestamp that is lower than the last-read global shard's for the node

> Counter values become under-counted when running repair.
> 
>
> Key: CASSANDRA-11432
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11432
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Aleksey Yeschenko
>
> We are experimenting Counters in Cassandra 2.2.5. Our setup is that we have 6 
> nodes, across three different regions, and in each region, the replication 
> factor is 2. Basically, each nodes holds a full copy of the data.
> We are writing to cluster with CL = 2, and reading with CL = 1. 
> When are doing 30k/s counter increment/decrement per node, and at the 
> meanwhile, we are double writing to our mysql tier, so that we can measure 
> the accuracy of C* counter, compared to mysql.
> The experiment result was great at the beginning, the counter value in C* and 
> mysql are very close. The difference is less than 0.1%. 
> But when we start to run the repair on one node, the counter value in C* 
> become much less than the value in mysql,  the difference becomes larger than 
> 1%.
> My question is that is it a known problem that the counter value will become 
> under-counted if repair is running? Should we avoid running repair for 
> counter tables?
> Thanks. 



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

[jira] [Commented] (CASSANDRA-11679) Cassandra Driver returns different number of results depending on fetchsize

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11679:
-

The patch looks good to me, but for some reason 
{{paging_test.TestPagingData.test_paging_for_range_name_queries}} failed in the 
unit tests.  Can you check on that?

> Cassandra Driver returns different number of results depending on fetchsize
> ---
>
> Key: CASSANDRA-11679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11679
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Varun Barala
>Assignee: Benjamin Lerer
> Fix For: 2.1.x
>
> Attachments: 11679-2.1.txt
>
>
> I'm trying to fetch all distinct keys from a CF using cassandra-driver 
> (2.1.7.1) and I observed some strange behavior :-
> The total distinct rows are 498 so If I perform a query get All distinctKeys 
> It returns 503 instead of 498(five keys twice).
> But If I define the fetch size in select statement more than 498 then it 
> returns exact 498 rows. 
> And If I execute same statement on Dev-center it returns 498 rows (because 
> the default fetch size is 5000). In `cqlsh` it returns 503 rows (because 
> cqlsh uses fetch size=100).
> Some Additional and useful information :- 
> ---
> Cassandra-2.1.13  (C)* version
> Consistency level: ONE 
> local machine(ubuntu 14.04)
> Table Schema:-
> --
> {code:xml}
> CREATE TABLE sample (
>  pk1 text,
>  pk2 text,
> row_id uuid,
> value blob,
> PRIMARY KEY (( pk1,  pk2))
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> query :-
> 
> {code:xml}
> SELECT DISTINCT  pk2, pk1 FROM sample LIMIT 2147483647;
> {code}



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

[jira] [Commented] (CASSANDRA-7826) support non-frozen, nested collections

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-7826:
-

bq. there's also the question if we would like to support arbitrary updates or 
deletes right away, too. That would require new syntax for selecting the path 
for update or delete (maybe something like mymap\['a'\]\['b'\]\[1\]

You're right, we'll need some new syntax here. But as to what we support, I'd 
say we can support the easily doable extensions of what we already support to 
any level of nestedness using square brackets. So if {{m}} is a {{map>}}, we'd support:
{noformat}
* m = { 'foo' : { 'bar' : { 2, 3 } } } and m = m + { 'foo' : { 'bar' : { 2, 3 } 
} };
* m['foo'] = { 'bar' : { 2, 3 } } and m['foo'] = m['foo'] + { 'bar' : { 2, 3 } 
};
* m['foo']['bar'] = {2, 3}, m['foo']['bar'] =  m['foo']['bar'] + {1} and 
m['foo']['bar'] = m['foo']['bar'] - {1}.
{noformat}

But as we currently have no way to delete a range of complex cells, we can only 
allow deleting elements in the most nested collection. Which is a bit annoying 
but adding range tombstone of complex cells is definitvely a follow-up ticket 
on its own imo.

bq. Also, BufferCell/tombstone can most likely handle deletes as they are, 
without slices, as we'll always know at least the partial path, but if I 
understand it correctly, it will require additional logic for discarding 
columns whose partial path matches the path of the tombstone.

I'm not entirely sure to follow. Are you suggesting to use a partial 
{{CellPath}} to implement deletion of a slice of complex cells?. If so, I 
suppose that's an option, but as said above, it's definitively something I 
would leave to a follow up ticket.

bq. most likely 7396 will land before this patch, so it we might have to add 
support for selecting individual parts on arbitrary level (or just on the top 
level at first and leave the rest for the next iterations). So the question is 
what we'd like to have on the current step.

I would agree that it probably make more sense to finish/commit CASSANDRA-7396 
first and rebasing this on top of it. Which does mean we'll have to think about 
sub-selections. That said, I suspect the existing {{ColumnSubSelection}} should 
be up to the task, aren't they? But if it's simpler to only support top level 
only at first and leave the rest to a followup, I personally won't mind.

bq. Non-frozen Set and List can be nested arbitrarily deep within the map, 
although nothing can be nested within Set or List.

Sgtm.

bq. At this particular moment I'm not entirely certain about the slices of keys 
for maps.

That can definitively be left to a follow-up ticket, assuming we even want to 
bother with it.


> support non-frozen, nested collections
> --
>
> Key: CASSANDRA-7826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7826
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Alex Petrov
>  Labels: ponies
> Fix For: 3.x
>
>
> The inability to nest collections is one of the bigger data modelling 
> limitations we have right now.



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

[jira] [Assigned] (CASSANDRA-10288) Incremental repair can hang if replica aren't all up (was: Inconsistent behaviours on repair when a node in RF is missing)

[Paulo Motta (JIRA)]

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

Paulo Motta reassigned CASSANDRA-10288:
---

Assignee: Paulo Motta  (was: Yuki Morishita)

> Incremental repair can hang if replica aren't all up (was: Inconsistent 
> behaviours on repair when a node in RF is missing)
> --
>
> Key: CASSANDRA-10288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10288
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Alan Boudreault
>Assignee: Paulo Motta
> Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1
>
> Attachments: repait_test.sh
>
>
> So with a cluster of 3 nodes and a RF=3 for my keyspace, I tried to repair my 
> data with a single node down. I got 3 different behaviours with different C* 
> versions. With:
> cassandra-2.1: it fails saying a node is down. (acceptable)
> cassandra-2.2: it hangs forever (???)
> cassandra-3.0: it completes successfully
> What is the correct behaviour of this repair use case? Obviously, 
> cassandra-2.2 has to be fixed, too.
> Here are the result logs when testing:
> cassandra-2.1
> {code}
> ccmlib.node.NodetoolError: Nodetool command 
> '/home/aboudreault/git/cstar/cassandra/bin/nodetool -h localhost -p 7100 
> repair test test' failed; exit status: 2; stdout: [2015-09-08 16:32:24,488] 
> Starting repair command #3, repairing 3 ranges for keyspace test 
> (parallelism=SEQUENTIAL, full=true)
> [2015-09-08 16:32:24,492] Repair session b69b5990-5668-11e5-b4ae-b3ffbc47f04c 
> for range (3074457345618258602,-9223372036854775808] failed with error 
> java.io.IOException: Cannot proceed on repair because a neighbor (/127.0.0.2) 
> is dead: session failed
> [2015-09-08 16:32:24,493] Repair session b69b80a0-5668-11e5-b4ae-b3ffbc47f04c 
> for range (-9223372036854775808,-3074457345618258603] failed with error 
> java.io.IOException: Cannot proceed on repair because a neighbor (/127.0.0.2) 
> is dead: session failed
> [2015-09-08 16:32:24,494] Repair session b69ba7b0-5668-11e5-b4ae-b3ffbc47f04c 
> for range (-3074457345618258603,3074457345618258602] failed with error 
> java.io.IOException: Cannot proceed on repair because a neighbor (/127.0.0.2) 
> is dead: session failed
> [2015-09-08 16:32:24,494] Repair command #3 finished
> ; stderr: error: nodetool failed, check server logs
> -- StackTrace --
> java.lang.RuntimeException: nodetool failed, check server logs
> at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:291)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:203)
> {code}
> cassandra-2.2:
> {code}
> just hangs  waited more than 10 minutes.
> {code}
> cassandra-3.0:
> {code}
> $ ccm node1 nodetool repair test test
> [2015-09-08 16:39:40,139] Starting repair command #1, repairing keyspace test 
> with repair options (parallelism: parallel, primary range: false, 
> incremental: true, job threads: 1, ColumnFamilies: [test], dataCenters: [], 
> hosts: [], # of ranges: 2)
> [2015-09-08 16:39:40,241] Repair session ba4a1440-5669-11e5-bc8e-b3ffbc47f04c 
> for range [(3074457345618258602,-9223372036854775808], 
> (-9223372036854775808,3074457345618258602]] finished (progress: 80%)
> [2015-09-08 16:39:40,267] Repair completed successfully
> [2015-09-08 16:39:40,270] Repair command #1 finished in 0 seconds
> {code}



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

[jira] [Commented] (CASSANDRA-7396) Allow selecting Map key, List index

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-7396:
-

Good point! Removed the slice deletions from the patch, pushed it and triggered 
CI.

> Allow selecting Map key, List index
> ---
>
> Key: CASSANDRA-7396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7396
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
>  Labels: cql, docs-impacting
> Fix For: 3.x
>
> Attachments: 7396_unit_tests.txt
>
>
> Allow "SELECT map['key]" and "SELECT list[index]."  (Selecting a UDT subfield 
> is already supported.)



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

[jira] [Commented] (CASSANDRA-11734) Enable partition component index for SASI

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai commented on CASSANDRA-11734:
-

bq. {{QueryController#hasIndexFor(ColumnDefinition)}} on every run of the 
results checking logic is very inefficient

Agree

So we'll postpone this JIRA until [CASSANDRA-10765] is done then

> Enable partition component index for SASI
> -
>
> Key: CASSANDRA-11734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11734
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>  Labels: doc-impacting, sasi, secondaryIndex
> Fix For: 3.8
>
> Attachments: patch.txt
>
>
> Enable partition component index for SASI
> For the given schema:
> {code:sql}
> CREATE TABLE test.comp (
> pk1 int,
> pk2 text,
> val text,
> PRIMARY KEY ((pk1, pk2))
> );
> CREATE CUSTOM INDEX comp_val_idx ON test.comp (val) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> CREATE CUSTOM INDEX comp_pk2_idx ON test.comp (pk2) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'mode': 'PREFIX', 
> 'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 
> 'case_sensitive': 'false'};
> CREATE CUSTOM INDEX comp_pk1_idx ON test.comp (pk1) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> {code}
> The following queries are possible:
> {code:sql}
> SELECT * FROM test.comp WHERE pk1=1;
> SELECT * FROM test.comp WHERE pk1>=1 AND pk1<=5;
> SELECT * FROM test.comp WHERE pk1=1 AND val='xxx' ALLOW FILTERING;
> SELECT * FROM test.comp WHERE pk1>=1 AND pk1<=5 AND val='xxx' ALLOW FILTERING;
> SELECT * FROM test.comp WHERE pk2='some text';
> SELECT * FROM test.comp WHERE pk2 LIKE 'prefix%';
> SELECT * FROM test.comp WHERE pk2='some text' AND val='xxx' ALLOW FILTERING;
> SELECT * FROM test.comp WHERE pk2 LIKE 'prefix%' AND val='xxx' ALLOW 
> FILTERING;
> //Without using SASI
> SELECT * FROM test.comp WHERE pk1 = 1 AND pk2='some text';
> SELECT * FROM test.comp WHERE pk1 IN(1,2,3) AND pk2='some text';
> SELECT * FROM test.comp WHERE pk1 = 1 AND pk2 IN ('text1','text2');
> SELECT * FROM test.comp WHERE pk1 IN(1,2,3) AND pk2 IN ('text1','text2');
> {code}
> However, the following queries *are not possible*
> {code:sql}
> SELECT * FROM test.comp WHERE pk1=1 AND pk2 LIKE 'prefix%';
> SELECT * FROM test.comp WHERE pk1>=1 AND pk1<=5 AND pk2 = 'some text';
> SELECT * FROM test.comp WHERE pk1>=1 AND pk1<=5 AND pk2 LIKE 'prefix%';
> {code}
> All of them are throwing the following exception
> {noformat}
> ava.lang.UnsupportedOperationException: null
>   at 
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$LikeRestriction.appendTo(SingleColumnRestriction.java:715)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.restrictions.PartitionKeySingleRestrictionSet.values(PartitionKeySingleRestrictionSet.java:86)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getPartitionKeys(StatementRestrictions.java:585)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:473)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:265)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:230)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:79)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.36.Final.jar:4.0.36.Final]
>   at 
> 

[jira] [Resolved] (CASSANDRA-11740) Nodes have wrong membership view of the cluster

[Joel Knighton (JIRA)]

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

Joel Knighton resolved CASSANDRA-11740.
---
Resolution: Duplicate

> Nodes have wrong membership view of the cluster
> ---
>
> Key: CASSANDRA-11740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11740
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
> Fix For: 2.2.x, 3.x
>
>
> We have a few hundreds nodes across 3 data centers, and we are doing a few 
> millions writes per second into the cluster.
> The problem we found is that there are some nodes (>10) have very wrong view 
> of the cluster.
> For example, we have 3 data centers A, B and C. On the problem nodes, in the 
> output of the 'nodetool status', it shows that ~100 nodes are not in data 
> center A, B, or C. Instead, it shows nodes are in DC1, and rack r1, which is 
> very wrong. And as a result, the node will return wrong results to client 
> requests.
> Datacenter: DC1
> ===
> Status=Up/Down
> / State=Normal/Leaving/Joining/Moving
> – Address Load Tokens Owns Host ID Rack
> UN 2401:db00:11:6134:face:0:1:0 509.52 GB 256 ? 
> e24656ac-c3b2-4117-b933-a5b06852c993 r1
> UN 2401:db00:11:b218:face:0:5:0 510.01 GB 256 ? 
> 53da2104-b1b5-4fa5-a3dd-52c7557149f9 r1
> UN 2401:db00:2130:5133:face:0:4d:0 459.75 GB 256 ? 
> ef8311f0-f6b8-491c-904d-baa925cdd7c2 r1
> We are using GossipingPropertyFileSnitch.
> Thanks



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

[jira] [Updated] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11279:

Status: Ready to Commit  (was: Patch Available)

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[jira] [Commented] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11279:
-

got it, thanks for the clarification!

+1, marking as ready to commit.

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[jira] [Commented] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11705:
---

Every time you add an unnecessary {{syncrhonized}} declaration, it makes 
someone like me scratch my head and waste my time on trying to understand why 
it's there. Should just grab the reference. Also, JDK has {{Arrays.copyOf()}} 
so that you wouldn't need to reinvent copying logic itself (:

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Updated] (CASSANDRA-7396) Allow selecting Map key, List index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-7396:

Reviewer: Sylvain Lebresne  (was: Tyler Hobbs)

> Allow selecting Map key, List index
> ---
>
> Key: CASSANDRA-7396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7396
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
>  Labels: cql, docs-impacting
> Fix For: 3.x
>
> Attachments: 7396_unit_tests.txt
>
>
> Allow "SELECT map['key]" and "SELECT list[index]."  (Selecting a UDT subfield 
> is already supported.)



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

[jira] [Commented] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-11705:
-

To prevent {{addInitialDirectories}} from changing {{initialDirectories}} while 
it's making a copy to return. Since we copy on write the {{initialDirectories}} 
value, I could just grab a reference to {{initialDirectories}} at the top of 
{{getInitialDirectories}} and copy from that instead, although both are called 
infrequently enough that I don't think it would make a difference.

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Commented] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11705:
---

What's the reason behind marking getInitialDirectories() as {{synchronized}}?

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Updated] (CASSANDRA-11705) clearSnapshots using Directories.dataDirectories instead of CFS.initialDirectories

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11705:
--
Fix Version/s: (was: 3.7)
   3.x

> clearSnapshots using Directories.dataDirectories instead of 
> CFS.initialDirectories
> --
>
> Key: CASSANDRA-11705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11705
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> An oversight in CASSANDRA-10518 prevents snapshots created in data 
> directories defined outside of cassandra.yaml from being cleared by 
> {{Keyspace.clearSnapshots}}. {{ColumnFamilyStore.initialDirectories}} should 
> be used when finding snapshots to clear, not {{Directories.dataDirectories}}



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

[jira] [Updated] (CASSANDRA-11463) dtest failure in compaction_test.TestCompaction_with_LeveledCompactionStrategy.bloomfilter_size_test

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-11463:

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

PR created and merged

> dtest failure in 
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.bloomfilter_size_test
> 
>
> Key: CASSANDRA-11463
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11463
> Project: Cassandra
>  Issue Type: Test
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> The final assertion {{self.assertGreaterEqual(bfSize, min_bf_size)}} is 
> failing with {{44728 not greater than or equal to 5}} on 2.1, pretty 
> consistently.
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/439/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/bloomfilter_size_test
> Failed on CassCI build cassandra-2.1_dtest #439



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

[jira] [Commented] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11279:
-

The new bootstrapping node is balanced, but the asserts check that the nodes we 
take ranges from are still balanced after running cleanup, and this is not as 
easy to do, and that is the reason we need CASSANDRA-11643

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.6 [deleted] c17cbe187

[jira] [Commented] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11279:
-

shouldn't disks be balanced (with a 20% tolerance) for a random distribution of 
workload + tokens? At least we could guarantee that, not much, but better than 
nothing :)

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[jira] [Commented] (CASSANDRA-7396) Allow selecting Map key, List index

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-7396:
-

bq. there's an idea to postpone the slice deletes

I *definitively* think we shouldn't support slice deletions here as we can't 
really do it properly. Doing a read-before-write is not only inefficient, it's 
wrong because what is deleted depends on when that read is done, but messages 
are never guaranteed to arrive in order to replicas. In other words, a 
read-before-write deletes will sometime not delete stuffs it should.

> Allow selecting Map key, List index
> ---
>
> Key: CASSANDRA-7396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7396
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
>  Labels: cql, docs-impacting
> Fix For: 3.x
>
> Attachments: 7396_unit_tests.txt
>
>
> Allow "SELECT map['key]" and "SELECT list[index]."  (Selecting a UDT subfield 
> is already supported.)



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

[jira] [Commented] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11279:
-

[~pauloricardomg] I don't think that will improve things? The randomness will 
still make those asserts fail at times, or am I missing something?

> dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
> --
>
> Key: CASSANDRA-11279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Marcus Eriksson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
> Failed on CassCI build trunk_dtest #1011
> This looks likely to be a test issue, perhaps we need to relax the assertion 
> here a bit:
> {noformat}
> values not within 20.00% of the max: (474650, 382235, 513385) (node1)
> {noformat}
> This is flaky with several flaps in the last few weeks.



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

[jira] [Updated] (CASSANDRA-11737) Add a way to disable severity in DynamicEndpointSnitch

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11737:
--
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   (was: 2.2.x)
   (was: 2.1.x)
   (was: 3.x)
   3.0.7
   3.7
   2.2.7
   2.1.15
   Status: Resolved  (was: Patch Available)

> Add a way to disable severity in DynamicEndpointSnitch
> --
>
> Key: CASSANDRA-11737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11737
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
> Fix For: 2.1.15, 2.2.7, 3.7, 3.0.7
>
>
> I have seen in a few clusters now where severity can out weigh latency in 
> DynamicEndpointSnitch causing issues (a node that is completely overloaded 
> CPU wise and has super high latency will get selected for queries, even 
> though nodes with much lower latency exist, but they have a higher severity 
> score).  There should be a way to disable the use of severity.



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

[jira] [Commented] (CASSANDRA-11737) Add a way to disable severity in DynamicEndpointSnitch

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11737:
---

Committed as 
[11d4e73e215cfe8baa16d9d6e0a589d6a94de56b|https://github.com/apache/cassandra/tree/cassandra-2.1]
 to 2.1 and merged with 2.2, 3.0, 3.7, and trunk.

> Add a way to disable severity in DynamicEndpointSnitch
> --
>
> Key: CASSANDRA-11737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11737
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> I have seen in a few clusters now where severity can out weigh latency in 
> DynamicEndpointSnitch causing issues (a node that is completely overloaded 
> CPU wise and has super high latency will get selected for queries, even 
> though nodes with much lower latency exist, but they have a higher severity 
> score).  There should be a way to disable the use of severity.



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

[01/15] cassandra git commit: Add option to disable use of severity in DynamicEndpointSnitch

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 aacd45263 -> 11d4e73e2
  refs/heads/cassandra-2.2 ac9844b99 -> e614433ce
  refs/heads/cassandra-3.0 ecb4ae8da -> e9657a43a
  refs/heads/cassandra-3.7 3f9025411 -> 04e7723e5
  refs/heads/trunk 58e11acdd -> 2d76bd4c6


Add option to disable use of severity in DynamicEndpointSnitch

patch by Jeremiah Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-11737


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

Branch: refs/heads/cassandra-2.1
Commit: 11d4e73e215cfe8baa16d9d6e0a589d6a94de56b
Parents: aacd452
Author: Jeremiah D Jordan 
Authored: Fri May 6 09:45:10 2016 -0500
Committer: Aleksey Yeschenko 
Committed: Tue May 10 15:59:02 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5885a9a..edf5aa3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.15
+ * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
  * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
  * Make cython optional in pylib/setup.py (CASSANDRA-11630)
  * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 6b6286f..c84ca27 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -40,6 +40,8 @@ import com.yammer.metrics.stats.ExponentiallyDecayingSample;
  */
 public class DynamicEndpointSnitch extends AbstractEndpointSnitch implements 
ILatencySubscriber, DynamicEndpointSnitchMBean
 {
+private static final boolean USE_SEVERITY = 
!Boolean.getBoolean("cassandra.ignore_dynamic_snitch_severity");
+
 private static final double ALPHA = 0.75; // set to 0.75 to make EDS more 
biased to towards the newer values
 private static final int WINDOW_SIZE = 100;
 
@@ -279,7 +281,8 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 double score = entry.getValue().getSnapshot().getMedian() / 
maxLatency;
 // finally, add the severity without any weighting, since hosts 
scale this relative to their own load and the size of the task causing the 
severity.
 // "Severity" is basically a measure of compaction activity 
(CASSANDRA-3722).
-score += StorageService.instance.getSeverity(entry.getKey());
+if (USE_SEVERITY)
+score += StorageService.instance.getSeverity(entry.getKey());
 // lowest score (least amount of badness) wins.
 newScores.put(entry.getKey(), score);
 }

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

[aleksey]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.7
Commit: e614433ce24199a2871f286115c75569d10f1c6f
Parents: ac9844b 11d4e73
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:39 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:39 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/CHANGES.txt
--
diff --cc CHANGES.txt
index 18cd90b,edf5aa3..2bb3518
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,5 +1,21 @@@
 -2.1.15
 +2.2.7
 + * Prohibit Reverse Counter type as part of the PK (CASSANDRA-9395)
 + * cqlsh: correctly handle non-ascii chars in error messages (CASSANDRA-11626)
 + * Exit JVM if JMX server fails to startup (CASSANDRA-11540)
 + * Produce a heap dump when exiting on OOM (CASSANDRA-9861)
 + * Avoid read repairing purgeable tombstones on range slices (CASSANDRA-11427)
 + * Restore ability to filter on clustering columns when using a 2i 
(CASSANDRA-11510)
 + * JSON datetime formatting needs timezone (CASSANDRA-11137)
 + * Fix is_dense recalculation for Thrift-updated tables (CASSANDRA-11502)
 + * Remove unnescessary file existence check during anticompaction 
(CASSANDRA-11660)
 + * Add missing files to debian packages (CASSANDRA-11642)
 + * Avoid calling Iterables::concat in loops during 
ModificationStatement::getFunctions (CASSANDRA-11621)
 + * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 +   report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
 + * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 + * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 +Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

[04/15] cassandra git commit: Add option to disable use of severity in DynamicEndpointSnitch

[aleksey]

Add option to disable use of severity in DynamicEndpointSnitch

patch by Jeremiah Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-11737


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

Branch: refs/heads/cassandra-3.0
Commit: 11d4e73e215cfe8baa16d9d6e0a589d6a94de56b
Parents: aacd452
Author: Jeremiah D Jordan 
Authored: Fri May 6 09:45:10 2016 -0500
Committer: Aleksey Yeschenko 
Committed: Tue May 10 15:59:02 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5885a9a..edf5aa3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.15
+ * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
  * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
  * Make cython optional in pylib/setup.py (CASSANDRA-11630)
  * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 6b6286f..c84ca27 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -40,6 +40,8 @@ import com.yammer.metrics.stats.ExponentiallyDecayingSample;
  */
 public class DynamicEndpointSnitch extends AbstractEndpointSnitch implements 
ILatencySubscriber, DynamicEndpointSnitchMBean
 {
+private static final boolean USE_SEVERITY = 
!Boolean.getBoolean("cassandra.ignore_dynamic_snitch_severity");
+
 private static final double ALPHA = 0.75; // set to 0.75 to make EDS more 
biased to towards the newer values
 private static final int WINDOW_SIZE = 100;
 
@@ -279,7 +281,8 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 double score = entry.getValue().getSnapshot().getMedian() / 
maxLatency;
 // finally, add the severity without any weighting, since hosts 
scale this relative to their own load and the size of the task causing the 
severity.
 // "Severity" is basically a measure of compaction activity 
(CASSANDRA-3722).
-score += StorageService.instance.getSeverity(entry.getKey());
+if (USE_SEVERITY)
+score += StorageService.instance.getSeverity(entry.getKey());
 // lowest score (least amount of badness) wins.
 newScores.put(entry.getKey(), score);
 }

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

[aleksey]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: e9657a43a8a64c1c273c15c166e88672cd0e55aa
Parents: ecb4ae8 e614433
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:59 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:59 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9657a43/CHANGES.txt
--
diff --cc CHANGES.txt
index af8be97,2bb3518..306f46f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -37,11 -13,9 +37,12 @@@ Merged from 2.2
   * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
   * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 - * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 + * Allow only DISTINCT queries with partition keys restrictions 
(CASSANDRA-11339)
 + * CqlConfigHelper no longer requires both a keystore and truststore to work 
(CASSANDRA-11532)
 + * Make deprecated repair methods backward-compatible with previous 
notification service (CASSANDRA-11430)
 + * IncomingStreamingConnection version check message wrong (CASSANDRA-11462)
  Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

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

[aleksey]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: e614433ce24199a2871f286115c75569d10f1c6f
Parents: ac9844b 11d4e73
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:39 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:39 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/CHANGES.txt
--
diff --cc CHANGES.txt
index 18cd90b,edf5aa3..2bb3518
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,5 +1,21 @@@
 -2.1.15
 +2.2.7
 + * Prohibit Reverse Counter type as part of the PK (CASSANDRA-9395)
 + * cqlsh: correctly handle non-ascii chars in error messages (CASSANDRA-11626)
 + * Exit JVM if JMX server fails to startup (CASSANDRA-11540)
 + * Produce a heap dump when exiting on OOM (CASSANDRA-9861)
 + * Avoid read repairing purgeable tombstones on range slices (CASSANDRA-11427)
 + * Restore ability to filter on clustering columns when using a 2i 
(CASSANDRA-11510)
 + * JSON datetime formatting needs timezone (CASSANDRA-11137)
 + * Fix is_dense recalculation for Thrift-updated tables (CASSANDRA-11502)
 + * Remove unnescessary file existence check during anticompaction 
(CASSANDRA-11660)
 + * Add missing files to debian packages (CASSANDRA-11642)
 + * Avoid calling Iterables::concat in loops during 
ModificationStatement::getFunctions (CASSANDRA-11621)
 + * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 +   report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
 + * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 + * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 +Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

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

[aleksey]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.7
Commit: e9657a43a8a64c1c273c15c166e88672cd0e55aa
Parents: ecb4ae8 e614433
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:59 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:59 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9657a43/CHANGES.txt
--
diff --cc CHANGES.txt
index af8be97,2bb3518..306f46f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -37,11 -13,9 +37,12 @@@ Merged from 2.2
   * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
   * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 - * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 + * Allow only DISTINCT queries with partition keys restrictions 
(CASSANDRA-11339)
 + * CqlConfigHelper no longer requires both a keystore and truststore to work 
(CASSANDRA-11532)
 + * Make deprecated repair methods backward-compatible with previous 
notification service (CASSANDRA-11430)
 + * IncomingStreamingConnection version check message wrong (CASSANDRA-11462)
  Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

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

[aleksey]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: e9657a43a8a64c1c273c15c166e88672cd0e55aa
Parents: ecb4ae8 e614433
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:59 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:59 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9657a43/CHANGES.txt
--
diff --cc CHANGES.txt
index af8be97,2bb3518..306f46f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -37,11 -13,9 +37,12 @@@ Merged from 2.2
   * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
   * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 - * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 + * Allow only DISTINCT queries with partition keys restrictions 
(CASSANDRA-11339)
 + * CqlConfigHelper no longer requires both a keystore and truststore to work 
(CASSANDRA-11532)
 + * Make deprecated repair methods backward-compatible with previous 
notification service (CASSANDRA-11430)
 + * IncomingStreamingConnection version check message wrong (CASSANDRA-11462)
  Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

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

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.7


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

Branch: refs/heads/cassandra-3.7
Commit: 04e7723e552459d4b96cea4b5bfbbc5773b0cd68
Parents: 3f90254 e9657a4
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:01:19 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:01:19 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/04e7723e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

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

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.7


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

Branch: refs/heads/trunk
Commit: 04e7723e552459d4b96cea4b5bfbbc5773b0cd68
Parents: 3f90254 e9657a4
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:01:19 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:01:19 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/04e7723e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

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

[aleksey]

Merge branch 'cassandra-3.7' into trunk


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

Branch: refs/heads/trunk
Commit: 2d76bd4c6a36156a22c4253cfd2e5d2cec55a450
Parents: 58e11ac 04e7723
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:01:32 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:01:32 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


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

[03/15] cassandra git commit: Add option to disable use of severity in DynamicEndpointSnitch

[aleksey]

Add option to disable use of severity in DynamicEndpointSnitch

patch by Jeremiah Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-11737


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

Branch: refs/heads/trunk
Commit: 11d4e73e215cfe8baa16d9d6e0a589d6a94de56b
Parents: aacd452
Author: Jeremiah D Jordan 
Authored: Fri May 6 09:45:10 2016 -0500
Committer: Aleksey Yeschenko 
Committed: Tue May 10 15:59:02 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5885a9a..edf5aa3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.15
+ * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
  * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
  * Make cython optional in pylib/setup.py (CASSANDRA-11630)
  * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 6b6286f..c84ca27 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -40,6 +40,8 @@ import com.yammer.metrics.stats.ExponentiallyDecayingSample;
  */
 public class DynamicEndpointSnitch extends AbstractEndpointSnitch implements 
ILatencySubscriber, DynamicEndpointSnitchMBean
 {
+private static final boolean USE_SEVERITY = 
!Boolean.getBoolean("cassandra.ignore_dynamic_snitch_severity");
+
 private static final double ALPHA = 0.75; // set to 0.75 to make EDS more 
biased to towards the newer values
 private static final int WINDOW_SIZE = 100;
 
@@ -279,7 +281,8 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 double score = entry.getValue().getSnapshot().getMedian() / 
maxLatency;
 // finally, add the severity without any weighting, since hosts 
scale this relative to their own load and the size of the task causing the 
severity.
 // "Severity" is basically a measure of compaction activity 
(CASSANDRA-3722).
-score += StorageService.instance.getSeverity(entry.getKey());
+if (USE_SEVERITY)
+score += StorageService.instance.getSeverity(entry.getKey());
 // lowest score (least amount of badness) wins.
 newScores.put(entry.getKey(), score);
 }

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

[aleksey]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: e614433ce24199a2871f286115c75569d10f1c6f
Parents: ac9844b 11d4e73
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:39 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:39 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/CHANGES.txt
--
diff --cc CHANGES.txt
index 18cd90b,edf5aa3..2bb3518
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,5 +1,21 @@@
 -2.1.15
 +2.2.7
 + * Prohibit Reverse Counter type as part of the PK (CASSANDRA-9395)
 + * cqlsh: correctly handle non-ascii chars in error messages (CASSANDRA-11626)
 + * Exit JVM if JMX server fails to startup (CASSANDRA-11540)
 + * Produce a heap dump when exiting on OOM (CASSANDRA-9861)
 + * Avoid read repairing purgeable tombstones on range slices (CASSANDRA-11427)
 + * Restore ability to filter on clustering columns when using a 2i 
(CASSANDRA-11510)
 + * JSON datetime formatting needs timezone (CASSANDRA-11137)
 + * Fix is_dense recalculation for Thrift-updated tables (CASSANDRA-11502)
 + * Remove unnescessary file existence check during anticompaction 
(CASSANDRA-11660)
 + * Add missing files to debian packages (CASSANDRA-11642)
 + * Avoid calling Iterables::concat in loops during 
ModificationStatement::getFunctions (CASSANDRA-11621)
 + * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 +   report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
 + * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 + * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 +Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

[02/15] cassandra git commit: Add option to disable use of severity in DynamicEndpointSnitch

[aleksey]

Add option to disable use of severity in DynamicEndpointSnitch

patch by Jeremiah Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-11737


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

Branch: refs/heads/cassandra-2.2
Commit: 11d4e73e215cfe8baa16d9d6e0a589d6a94de56b
Parents: aacd452
Author: Jeremiah D Jordan 
Authored: Fri May 6 09:45:10 2016 -0500
Committer: Aleksey Yeschenko 
Committed: Tue May 10 15:59:02 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5885a9a..edf5aa3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.15
+ * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
  * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
  * Make cython optional in pylib/setup.py (CASSANDRA-11630)
  * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 6b6286f..c84ca27 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -40,6 +40,8 @@ import com.yammer.metrics.stats.ExponentiallyDecayingSample;
  */
 public class DynamicEndpointSnitch extends AbstractEndpointSnitch implements 
ILatencySubscriber, DynamicEndpointSnitchMBean
 {
+private static final boolean USE_SEVERITY = 
!Boolean.getBoolean("cassandra.ignore_dynamic_snitch_severity");
+
 private static final double ALPHA = 0.75; // set to 0.75 to make EDS more 
biased to towards the newer values
 private static final int WINDOW_SIZE = 100;
 
@@ -279,7 +281,8 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 double score = entry.getValue().getSnapshot().getMedian() / 
maxLatency;
 // finally, add the severity without any weighting, since hosts 
scale this relative to their own load and the size of the task causing the 
severity.
 // "Severity" is basically a measure of compaction activity 
(CASSANDRA-3722).
-score += StorageService.instance.getSeverity(entry.getKey());
+if (USE_SEVERITY)
+score += StorageService.instance.getSeverity(entry.getKey());
 // lowest score (least amount of badness) wins.
 newScores.put(entry.getKey(), score);
 }

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

[aleksey]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.0
Commit: e614433ce24199a2871f286115c75569d10f1c6f
Parents: ac9844b 11d4e73
Author: Aleksey Yeschenko 
Authored: Tue May 10 16:00:39 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue May 10 16:00:39 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/CHANGES.txt
--
diff --cc CHANGES.txt
index 18cd90b,edf5aa3..2bb3518
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,20 -1,5 +1,21 @@@
 -2.1.15
 +2.2.7
 + * Prohibit Reverse Counter type as part of the PK (CASSANDRA-9395)
 + * cqlsh: correctly handle non-ascii chars in error messages (CASSANDRA-11626)
 + * Exit JVM if JMX server fails to startup (CASSANDRA-11540)
 + * Produce a heap dump when exiting on OOM (CASSANDRA-9861)
 + * Avoid read repairing purgeable tombstones on range slices (CASSANDRA-11427)
 + * Restore ability to filter on clustering columns when using a 2i 
(CASSANDRA-11510)
 + * JSON datetime formatting needs timezone (CASSANDRA-11137)
 + * Fix is_dense recalculation for Thrift-updated tables (CASSANDRA-11502)
 + * Remove unnescessary file existence check during anticompaction 
(CASSANDRA-11660)
 + * Add missing files to debian packages (CASSANDRA-11642)
 + * Avoid calling Iterables::concat in loops during 
ModificationStatement::getFunctions (CASSANDRA-11621)
 + * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 +   report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
 + * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 + * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 +Merged from 2.1:
+  * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
   * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
   * Make cython optional in pylib/setup.py (CASSANDRA-11630)
   * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e614433c/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--

[05/15] cassandra git commit: Add option to disable use of severity in DynamicEndpointSnitch

[aleksey]

Add option to disable use of severity in DynamicEndpointSnitch

patch by Jeremiah Jordan; reviewed by Aleksey Yeschenko for
CASSANDRA-11737


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

Branch: refs/heads/cassandra-3.7
Commit: 11d4e73e215cfe8baa16d9d6e0a589d6a94de56b
Parents: aacd452
Author: Jeremiah D Jordan 
Authored: Fri May 6 09:45:10 2016 -0500
Committer: Aleksey Yeschenko 
Committed: Tue May 10 15:59:02 2016 +0100

--
 CHANGES.txt | 1 +
 .../org/apache/cassandra/locator/DynamicEndpointSnitch.java | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5885a9a..edf5aa3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.15
+ * Add option to disable use of severity in DynamicEndpointSnitch 
(CASSANDRA-11737)
  * cqlsh COPY FROM fails for null values with non-prepared statements 
(CASSANDRA-11631)
  * Make cython optional in pylib/setup.py (CASSANDRA-11630)
  * Change order of directory searching for cassandra.in.sh to favor local one 
(CASSANDRA-11628)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/11d4e73e/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 6b6286f..c84ca27 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -40,6 +40,8 @@ import com.yammer.metrics.stats.ExponentiallyDecayingSample;
  */
 public class DynamicEndpointSnitch extends AbstractEndpointSnitch implements 
ILatencySubscriber, DynamicEndpointSnitchMBean
 {
+private static final boolean USE_SEVERITY = 
!Boolean.getBoolean("cassandra.ignore_dynamic_snitch_severity");
+
 private static final double ALPHA = 0.75; // set to 0.75 to make EDS more 
biased to towards the newer values
 private static final int WINDOW_SIZE = 100;
 
@@ -279,7 +281,8 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 double score = entry.getValue().getSnapshot().getMedian() / 
maxLatency;
 // finally, add the severity without any weighting, since hosts 
scale this relative to their own load and the size of the task causing the 
severity.
 // "Severity" is basically a measure of compaction activity 
(CASSANDRA-3722).
-score += StorageService.instance.getSeverity(entry.getKey());
+if (USE_SEVERITY)
+score += StorageService.instance.getSeverity(entry.getKey());
 // lowest score (least amount of badness) wins.
 newScores.put(entry.getKey(), score);
 }

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.6-tentative [deleted] 5634cea37

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Tags:  refs/tags/3.6-tentative [created] c17cbe187

[jira] [Created] (CASSANDRA-11743) Race condition in CommitLog.recover can prevent startup

[Benjamin Lerer (JIRA)]

Benjamin Lerer created CASSANDRA-11743:
--

 Summary: Race condition in CommitLog.recover can prevent startup
 Key: CASSANDRA-11743
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11743
 Project: Cassandra
  Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer


In {{CommitLog::recover}} the list of segments to recover from is determined by 
removing the files managed by the {{CommitLogSegmentManager}} from the list of 
files present in the commit log directory. Unfortunatly, due to the way the 
creation of segments is done there is a time window where a segment file has 
been created but has not been added yet to the list of segments managed by the 
{{CommitLogSegmentManager}}. If the filtering ocurs during that time window the 
Commit log might try to recover from that new segment and crash.   



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

[jira] [Commented] (CASSANDRA-7581) Stop read requests for partitions which don't belong to a node

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-7581:


This issue looks related to 
[7592|https://issues.apache.org/jira/browse/CASSANDRA-7592], although 7592 
seems to have a more complete scope description. Although suggested solution 
might solve both issues: by dropping read requests coordinator will be able to 
pick another node to read from.

This problem seems not to apply to local mutations, as they're always checked 
for {{appliesLocally}}. So in the end it might be a good idea to have similar 
flow for reads.

> Stop read requests for partitions which don't belong to a node
> --
>
> Key: CASSANDRA-7581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7581
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Alex Petrov
>Priority: Minor
>
> A C* instance will serve CF level reads with null values or old values to a 
> co-ordinator even if the instance is not responsible for the data. 
> This is bad if co-ordinator has a wrong view of the ring and will return 
> wrong results back to the client. 
> A solution to this problem could be to not respond or return error to such 
> read requests. 
> Tricky part here is to respond to read requests when the instance has just 
> lost ownership for a few ring delay. 
>  



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

[1/6] cassandra git commit: Allow service to startup if jmx remote port configured directly

[samt]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.6 31cab36b1 -> c17cbe187
  refs/heads/cassandra-3.7 a093e8cae -> 3f9025411
  refs/heads/trunk 653d0bffc -> 58e11acdd


Allow service to startup if jmx remote port configured directly

Patch by Sam Tunnicliffe; reviewed by Jake Luciani for CASSANDRA-11725


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

Branch: refs/heads/cassandra-3.6
Commit: c17cbe1875a974a00822ffbfad716abde363c8da
Parents: 31cab36
Author: Sam Tunnicliffe 
Authored: Mon May 9 19:23:33 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue May 10 14:57:25 2016 +0100

--
 CHANGES.txt |  1 +
 NEWS.txt|  2 ++
 .../cassandra/service/CassandraDaemon.java  | 13 
 .../apache/cassandra/service/StartupChecks.java | 21 ++--
 .../apache/cassandra/utils/JMXServerUtils.java  | 20 +++
 5 files changed, 38 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b7715ba..1690e09 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.6
+ * Allow server startup if JMX is configured directly (CASSANDRA-11725)
  * Prevent direct memory OOM on buffer pool allocations (CASSANDRA-11710)
  * Enhanced Compaction Logging (CASSANDRA-10805)
  * Make prepared statement cache size configurable (CASSANDRA-11555)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 7a29924..ac33a60 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -25,6 +25,8 @@ New features
  connections are permitted. For more details on how to enable the new 
options, see the
  comments in cassandra-env.sh. A new class of IResource, JMXResource, is 
provided for
  the purposes of GRANT/REVOKE via CQL. See CASSANDRA-10091 for more 
details.
+ Also, directly setting JMX remote port via the 
com.sun.management.jmxremote.port system
+ property at startup is deprecated. See CASSANDRA-11725 for more details.
- JSON timestamps are now in UTC and contain the timezone information, see 
CASSANDRA-11137 for more details.
- Collision checks are performed when joining the token ring, regardless of 
whether
  the node should bootstrap. Additionally, replace_address can legitimately 
be used

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index 2b797fe..2bf4931 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -97,6 +97,19 @@ public class CassandraDaemon
 
 private void maybeInitJmx()
 {
+// If the standard com.sun.management.jmxremote.port property has been 
set
+// then the JVM agent will have already started up a default JMX 
connector
+// server. This behaviour is deprecated, but some clients may be 
relying
+// on it, so log a warning and skip setting up the server with the 
settings
+// as configured in cassandra-env.(sh|ps1)
+// See: CASSANDRA-11540 & CASSANDRA-11725
+if (System.getProperty("com.sun.management.jmxremote.port") != null)
+{
+logger.warn("JMX settings in cassandra-env.sh have been bypassed 
as the JMX connector server is " +
+"already initialized. Please refer to 
cassandra-env.(sh|ps1) for JMX configuration info");
+return;
+}
+
 System.setProperty("java.rmi.server.randomIDs", "true");
 
 // If a remote port has been specified then use that to set up a JMX

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/src/java/org/apache/cassandra/service/StartupChecks.java
--
diff --git a/src/java/org/apache/cassandra/service/StartupChecks.java 
b/src/java/org/apache/cassandra/service/StartupChecks.java
index d1c1943..d837921 100644
--- a/src/java/org/apache/cassandra/service/StartupChecks.java
+++ b/src/java/org/apache/cassandra/service/StartupChecks.java
@@ -32,12 +32,16 @@ import org.slf4j.LoggerFactory;
 import 

[3/6] cassandra git commit: Allow service to startup if jmx remote port configured directly

[samt]

Allow service to startup if jmx remote port configured directly

Patch by Sam Tunnicliffe; reviewed by Jake Luciani for CASSANDRA-11725


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

Branch: refs/heads/trunk
Commit: c17cbe1875a974a00822ffbfad716abde363c8da
Parents: 31cab36
Author: Sam Tunnicliffe 
Authored: Mon May 9 19:23:33 2016 +0100
Committer: Sam Tunnicliffe 
Committed: Tue May 10 14:57:25 2016 +0100

--
 CHANGES.txt |  1 +
 NEWS.txt|  2 ++
 .../cassandra/service/CassandraDaemon.java  | 13 
 .../apache/cassandra/service/StartupChecks.java | 21 ++--
 .../apache/cassandra/utils/JMXServerUtils.java  | 20 +++
 5 files changed, 38 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b7715ba..1690e09 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.6
+ * Allow server startup if JMX is configured directly (CASSANDRA-11725)
  * Prevent direct memory OOM on buffer pool allocations (CASSANDRA-11710)
  * Enhanced Compaction Logging (CASSANDRA-10805)
  * Make prepared statement cache size configurable (CASSANDRA-11555)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 7a29924..ac33a60 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -25,6 +25,8 @@ New features
  connections are permitted. For more details on how to enable the new 
options, see the
  comments in cassandra-env.sh. A new class of IResource, JMXResource, is 
provided for
  the purposes of GRANT/REVOKE via CQL. See CASSANDRA-10091 for more 
details.
+ Also, directly setting JMX remote port via the 
com.sun.management.jmxremote.port system
+ property at startup is deprecated. See CASSANDRA-11725 for more details.
- JSON timestamps are now in UTC and contain the timezone information, see 
CASSANDRA-11137 for more details.
- Collision checks are performed when joining the token ring, regardless of 
whether
  the node should bootstrap. Additionally, replace_address can legitimately 
be used

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index 2b797fe..2bf4931 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -97,6 +97,19 @@ public class CassandraDaemon
 
 private void maybeInitJmx()
 {
+// If the standard com.sun.management.jmxremote.port property has been 
set
+// then the JVM agent will have already started up a default JMX 
connector
+// server. This behaviour is deprecated, but some clients may be 
relying
+// on it, so log a warning and skip setting up the server with the 
settings
+// as configured in cassandra-env.(sh|ps1)
+// See: CASSANDRA-11540 & CASSANDRA-11725
+if (System.getProperty("com.sun.management.jmxremote.port") != null)
+{
+logger.warn("JMX settings in cassandra-env.sh have been bypassed 
as the JMX connector server is " +
+"already initialized. Please refer to 
cassandra-env.(sh|ps1) for JMX configuration info");
+return;
+}
+
 System.setProperty("java.rmi.server.randomIDs", "true");
 
 // If a remote port has been specified then use that to set up a JMX

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c17cbe18/src/java/org/apache/cassandra/service/StartupChecks.java
--
diff --git a/src/java/org/apache/cassandra/service/StartupChecks.java 
b/src/java/org/apache/cassandra/service/StartupChecks.java
index d1c1943..d837921 100644
--- a/src/java/org/apache/cassandra/service/StartupChecks.java
+++ b/src/java/org/apache/cassandra/service/StartupChecks.java
@@ -32,12 +32,16 @@ import org.slf4j.LoggerFactory;
 import org.apache.cassandra.config.CFMetaData;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.config.Schema;
-import org.apache.cassandra.db.*;
+import