[jira] [Updated] (CASSANDRA-15162) IndexNotAvailableException: The secondary index 'idx_ma_transaction_id' is not yet available

2019-06-14 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15162:
-
Resolution: Invalid
Status: Resolved  (was: Triage Needed)

Please use the user mailing list or the Cassandra room in Slack for operations 
questions.  From first glance, this is just a matter of the index still being 
built.

See http://cassandra.apache.org/doc/latest/contactus.html

> IndexNotAvailableException: The secondary index 'idx_ma_transaction_id' is 
> not yet available
> 
>
> Key: CASSANDRA-15162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15162
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Schema
>Reporter: Pradip Kumar
>Priority: Normal
>
> Hi,
> I created an index on the table "moneyid_allocation" as below..
> *CREATE INDEX idx_ma_transaction_id ON moneymarking.moneyid_allocation 
> (transaction_id);*
> But when I am selecting the data by using the indexed column the got error in 
> the system.log, Please suggest to resolve the issue
> There are around 10 million records in the table.
>  
> *select query:-*
> select * from moneyid_allocation where transaction_id='11' limit 1 
> ALLOW FILTERING;
> *Error in system.log:-*
> WARN  [ReadStage-4] 2019-06-14 23:28:56,666 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-4,5,main]: {}
> java.lang.RuntimeException: 
> org.apache.cassandra.index.IndexNotAvailableException: The secondary index 
> 'idx_ma_transaction_id' is not yet available
>     at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
>     at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_161]
>     at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
>     at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.3.jar:3.11.3]
>     at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.3.jar:3.11.3]
>     at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
> Caused by: org.apache.cassandra.index.IndexNotAvailableException: The 
> secondary index 'idx_ma_transaction_id' is not yet available
>     at 
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:416) 
> ~[apache-cassandra-3.11.3.jar:3.11.3]
>     at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1887)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
>     at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2597)
>  ~[apache-cassandra-3.11.3.jar:3.11.3]
>     ... 5 common frames omitted
>  
> Regards,
> Pradip
>  



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

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



[jira] [Commented] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

2019-06-14 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna commented on CASSANDRA-15149:
--

As a note, I bulk changed all unresolved tickets with the lhf label to have the 
Low Hanging Fruit complexity.  That makes it so we can just use the Low Hanging 
Fruit complexity in the query going forward.  So that's what I did in the link 
change in the docs.

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Fix For: 4.0
>
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



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

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



[jira] [Assigned] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna reassigned CASSANDRA-13990:


Assignee: Pedro Gordo

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Assignee: Pedro Gordo
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



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

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



[jira] [Commented] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna commented on CASSANDRA-13990:
--

Go for it.  I'm just double checking around to see if there are any final 
objections to do this in principle.

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



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

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



[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15149:
-
Attachment: CASSANDRA-15149.txt

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



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

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



[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15149:
-
Attachment: (was: CASSANDRA-15149.txt)

> Change the text and link for low hanging fruit tickets to include the LHF 
> ticket complexity
> ---
>
> Key: CASSANDRA-15149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15149
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Normal
> Attachments: CASSANDRA-15149.txt
>
>
> Right now in the docs for how to contribute, it points to the lhf (low 
> hanging fruit) label which is how things were marked before the Jira flow 
> evolution.  We should note the complexity field in there and include both the 
> label and the complexity field in the associated link.



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

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



[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11418:
-
Complexity: Low Hanging Fruit

> Nodetool status should reflect hibernate/replacing states
> -
>
> Key: CASSANDRA-11418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Tool/nodetool
>Reporter: Joel Knighton
>Assignee: Shaurya Gupta
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: cassandra-11418-trunk
>
>
> Currently, the four options for state in nodetool status are 
> joining/leaving/moving/normal.
> Joining nodes are determined based on bootstrap tokens, leaving nodes are 
> based on leaving endpoints in TokenMetadata, moving nodes are based on moving 
> endpoints in TokenMetadata.
> This means that a node will appear in normal state when going through a 
> bootstrap with flag replace_address, which can be confusing to operators.
> We should add another state for hibernation/replacing to make this visible. 
> This will require a way to get a list of all hibernating endpoints.



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

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



[jira] [Updated] (CASSANDRA-10968) When taking snapshot, manifest.json contains incorrect or no files when column family has secondary indexes

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-10968:
-
Complexity: Low Hanging Fruit

> When taking snapshot, manifest.json contains incorrect or no files when 
> column family has secondary indexes
> ---
>
> Key: CASSANDRA-10968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10968
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
>Reporter: Fred A
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> xNoticed indeterminate behaviour when taking snapshot on column families that 
> has secondary indexes setup. The created manifest.json created when doing 
> snapshot, sometimes contains no file names at all and sometimes some file 
> names. 
> I don't know if this post is related but that was the only thing I could find:
> http://www.mail-archive.com/user%40cassandra.apache.org/msg42019.html



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

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



[jira] [Updated] (CASSANDRA-12849) The parameter -XX:HeapDumpPath is not ovewritten by cassandra-env.sh

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12849:
-
Complexity: Low Hanging Fruit

> The parameter  -XX:HeapDumpPath is not ovewritten by cassandra-env.sh
> -
>
> Key: CASSANDRA-12849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: jean carlo rivera ura
>Priority: Normal
>  Labels: lhf
> Attachments: 12849-trunk.txt
>
>
> The parameter  -XX:HeapDumpPath appears twice in the java process 
> {panel}
> user@node:~$ sudo ps aux | grep --color  HeapDumpPath
> java -ea -javaagent:/usr/share/cassandra/lib/jamm-0.3.0.jar 
> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities 
> -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn200M 
> -XX:+HeapDumpOnOutOfMemoryError 
> -XX:*HeapDumpPath*=/var/lib/cassandra-1477577769-pid1516.hprof -Xss256k 
> ...
> -XX:*HeapDumpPath*=/home/cassandra/java_1477577769.hprof 
> -XX:ErrorFile=/var/lib/cassandra/hs_err_1477577769.log 
> org.apache.cassandra.service.CassandraDaemon
> {panel}
> The problem is when we have an OOM error, the JVM dump goes to 
> */home/cassandra/java_1477577769.hprof * when the correct behavior is to go 
> to the path defined by cassandra-env.sh  
> */var/lib/cassandra-1477577769-pid1516.hprof*
> This is quite annoying because cassandra takes into account only the path 
> defined by the script init (usually that disk is not that big to keep 8Gb of 
> a heap dump) and not the path defined in cassandra-env.sh
> {noformat}
> user@node:~$ jmx4perl http://localhost:8523/jolokia read 
> com.sun.management:type=HotSpotDiagnostic DiagnosticOptions
>  {
> name => 'HeapDumpPath',
> origin => 'VM_CREATION',
> value => '/home/cassandra/java_1477043835.hprof',
> writeable => '[true]'
>   },
> {noformat}



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

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



[jira] [Updated] (CASSANDRA-9430) Add startup options to cqlshrc

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-9430:

Complexity: Low Hanging Fruit

> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the 
> cqlshrc file.  For example, a user may want to set the paging to off by 
> default for their environment.  You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default 
> settings on startup.



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

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



[jira] [Updated] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12757:
-
Complexity: Low Hanging Fruit

> NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
> --
>
> Key: CASSANDRA-12757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Jeremiah Jordan
>Assignee: Damien Stevenson
>Priority: Normal
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
>
> If the keyspace specified in allocate_tokens_for_keyspace does not exist you 
> get an NPE.  Should probably have a better error here letting people know 
> what the issue was.
> {code}
> INFO  21:07:22,582  StorageService.java:1152 - JOINING: getting bootstrap 
> token
> Exception (java.lang.NullPointerException) encountered during startup: null
> ERROR 21:07:22,590  CassandraDaemon.java:709 - Exception encountered during 
> startup
> java.lang.NullPointerException: null
>at 
> org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.(Keyspace.java:298) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201) 
> ~[cassandra-all-3.0.8.jar:3.0.8]
>at 
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
>  ~[cassandra-all-3.0.8:3.0.8]
> {code}



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

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



[jira] [Updated] (CASSANDRA-9452) Remove configuration of storage-conf from tools

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-9452:

Complexity: Low Hanging Fruit

> Remove configuration of storage-conf from tools
> ---
>
> Key: CASSANDRA-9452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9452
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Testing, Legacy/Tools, Local/Config
>Reporter: Mike Adamson
>Assignee: Vinay Chella
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: CASSANDRA-14092-trunk_v1.txt, CASSANDRA-9452-trunk.txt
>
>
> The following files still making reference to storage-config and/or 
> storage-conf.xml
> * ./build.xml
> * ./bin/nodetool
> * ./bin/sstablekeys
> * ./test/resources/functions/configure_cassandra.sh
> * ./test/resources/functions/install_cassandra.sh
> * ./tools/bin/json2sstable
> * ./tools/bin/sstable2json
> * ./tools/bin/sstablelevelreset



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

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



[jira] [Updated] (CASSANDRA-9289) Recover from unknown table when deserializing internode messages

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-9289:

Complexity: Low Hanging Fruit

> Recover from unknown table when deserializing internode messages
> 
>
> Key: CASSANDRA-9289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9289
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Assignee: ZhaoYang
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
>
> As discussed in CASSANDRA-9136, it would be nice to gracefully recover from 
> seeing an unknown table in a message from another node.  Currently, we close 
> the connection and reconnect, which can cause other concurrent queries to 
> fail.



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

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



[jira] [Updated] (CASSANDRA-12972) Print stress-tool output header about each 30 secs.

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12972:
-
Complexity: Low Hanging Fruit

> Print stress-tool output header about each 30 secs.
> ---
>
> Key: CASSANDRA-12972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12972
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools, Tool/stress
>Reporter: Vovodroid
>Assignee: Vovodroid
>Priority: Low
>  Labels: lhf
> Attachments: 3.11.patch
>
>
> Currently header with columns meaning is printed only on test beginning. If 
> test is long it's not handy to interpret rows with numbers only.
> I propose to repeatably print headers each half-minute or so.
> Patch is available, is this improvement needed?
> Thanks.



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

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



[jira] [Updated] (CASSANDRA-12701) Repair history tables should have TTL and TWCS

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12701:
-
Complexity: Low Hanging Fruit

> Repair history tables should have TTL and TWCS
> --
>
> Key: CASSANDRA-12701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12701
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Chris Lohfink
>Priority: Normal
>  Labels: lhf
> Attachments: CASSANDRA-12701.txt
>
>
> Some tools schedule a lot of small subrange repairs which can lead to a lot 
> of repairs constantly being run. These partitions can grow pretty big in 
> theory. I dont think much reads from them which might help but its still 
> kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe 
> a 1 day twcs window makes sense to me.



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

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



[jira] [Updated] (CASSANDRA-12922) Bloom filter miss counts are not measured correctly

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12922:
-
Complexity: Low Hanging Fruit

> Bloom filter miss counts are not measured correctly
> ---
>
> Key: CASSANDRA-12922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12922
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Sundar Srinivasan
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 12922-trunk.txt
>
>
> Bloom filter hits and misses are evaluated incorrectly in 
> {{BigTableReader.getPosition}}: we properly record hits, but not misses. In 
> particular, if we don't find a match for a key in the index, which is where 
> almost all non-matches will be rejected, [we don't record a bloom filter 
> false 
> positive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L228].
> This leads to very misleading output from e.g. {{nodetool tablestats}}.



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

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



[jira] [Updated] (CASSANDRA-14128) Prune dead links from cassandra.apache.org

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14128:
-
Complexity: Low Hanging Fruit

> Prune dead links from cassandra.apache.org
> --
>
> Key: CASSANDRA-14128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14128
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Jeff Jirsa
>Assignee: Kurt Greaves
>Priority: Low
>  Labels: lhf
> Attachments: 14128-site.patch
>
>
> Lots of dead links on the site, including the homepage. Should do some 
> pruning cleanup.
> Site repo is [here|https://svn.apache.org/repos/asf/cassandra/site/] (in svn) 
> for anyone who wishes to give this a shot.



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

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



[jira] [Updated] (CASSANDRA-13917) COMPACT STORAGE queries on dense static tables accept hidden column1 and value columns

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13917:
-
Complexity: Low Hanging Fruit

> COMPACT STORAGE queries on dense static tables accept hidden column1 and 
> value columns
> --
>
> Key: CASSANDRA-13917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13917
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Alex Petrov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13917-3.0-testall-2.png, 13917-3.0.png, 
> 13917-3.11-testall-2.png, 13917-3.11.png
>
>
> Test for the issue:
> {code}
> @Test
> public void testCompactStorage() throws Throwable
> {
> createTable("CREATE TABLE %s (a int PRIMARY KEY, b int, c int) WITH 
> COMPACT STORAGE");
> assertInvalid("INSERT INTO %s (a, b, c, column1) VALUES (?, ?, ?, 
> ?)", 1, 1, 1, ByteBufferUtil.bytes('a'));
> // This one fails with Some clustering keys are missing: column1, 
> which is still wrong
> assertInvalid("INSERT INTO %s (a, b, c, value) VALUES (?, ?, ?, ?)", 
> 1, 1, 1, ByteBufferUtil.bytes('a'));   
> assertInvalid("INSERT INTO %s (a, b, c, column1, value) VALUES (?, ?, 
> ?, ?, ?)", 1, 1, 1, ByteBufferUtil.bytes('a'), ByteBufferUtil.bytes('b'));
> assertEmpty(execute("SELECT * FROM %s"));
> }
> {code}
> Gladly, these writes are no-op, even though they succeed.
> {{value}} and {{column1}} should be completely hidden. Fixing this one should 
> be as easy as just adding validations.



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

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



[jira] [Updated] (CASSANDRA-12273) Casandra stress graph: option to create directory for graph if it doesn't exist

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12273:
-
Complexity: Low Hanging Fruit

> Casandra stress graph: option to create directory for graph if it doesn't 
> exist
> ---
>
> Key: CASSANDRA-12273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12273
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Christopher Batey
>Assignee: Murukesh Mohanan
>Priority: Low
>  Labels: lhf
> Attachments: 12273.patch
>
>
> I am running it in CI with ephemeral workspace  / build dirs. It would be 
> nice if CS would create the directory so my build tool doesn't have to



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

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



[jira] [Updated] (CASSANDRA-13692) CompactionAwareWriter_getWriteDirectory throws incompatible exceptions

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13692:
-
Complexity: Low Hanging Fruit

> CompactionAwareWriter_getWriteDirectory throws incompatible exceptions
> --
>
> Key: CASSANDRA-13692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction
>Reporter: Hao Zhong
>Assignee: Dimitar Dimitrov
>Priority: Normal
>  Labels: lhf
> Attachments: c13692-2.2-dtest-results.PNG, 
> c13692-2.2-testall-results.PNG, c13692-3.0-dtest-results-updated.PNG, 
> c13692-3.0-dtest-results.PNG, c13692-3.0-testall-results.PNG, 
> c13692-3.11-dtest-results-updated.PNG, c13692-3.11-dtest-results.PNG, 
> c13692-3.11-testall-results.PNG, c13692-dtest-results-updated.PNG, 
> c13692-dtest-results.PNG, c13692-testall-results-updated.PNG, 
> c13692-testall-results.PNG
>
>
> The CompactionAwareWriter_getWriteDirectory throws RuntimeException:
> {code}
> public Directories.DataDirectory getWriteDirectory(Iterable 
> sstables, long estimatedWriteSize)
> {
> File directory = null;
> for (SSTableReader sstable : sstables)
> {
> if (directory == null)
> directory = sstable.descriptor.directory;
> if (!directory.equals(sstable.descriptor.directory))
> {
> logger.trace("All sstables not from the same disk - putting 
> results in {}", directory);
> break;
> }
> }
> Directories.DataDirectory d = 
> getDirectories().getDataDirectoryForFile(directory);
> if (d != null)
> {
> long availableSpace = d.getAvailableSpace();
> if (availableSpace < estimatedWriteSize)
> throw new RuntimeException(String.format("Not enough space to 
> write %s to %s (%s available)",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize),
>  d.location,
>  
> FBUtilities.prettyPrintMemory(availableSpace)));
> logger.trace("putting compaction results in {}", directory);
> return d;
> }
> d = getDirectories().getWriteableLocation(estimatedWriteSize);
> if (d == null)
> throw new RuntimeException(String.format("Not enough disk space 
> to store %s",
>  
> FBUtilities.prettyPrintMemory(estimatedWriteSize)));
> return d;
> }
> {code}
> However, the thrown exception does not  trigger the failure policy. 
> CASSANDRA-11448 fixed a similar problem. The buggy code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new RuntimeException("Insufficient disk space to write " + 
> writeSize + " bytes");
> return directory;
> }
> {code}
> The fixed code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory = 
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new FSWriteError(new IOException("Insufficient disk space 
> to write " + writeSize + " bytes"), "");
> return directory;
> }
> {code}
> The fixed code throws FSWE and triggers the failure policy.



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

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



[jira] [Updated] (CASSANDRA-14410) tablehistograms with non-existent table gives an exception

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14410:
-
Complexity: Low Hanging Fruit

> tablehistograms with non-existent table gives an exception
> --
>
> Key: CASSANDRA-14410
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14410
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Normal
>  Labels: lhf
> Fix For: 3.11.x, 4.x
>
>
> nodetool tablehistograms with non-existent table gives a crazy exception. It 
> should give a nice error message like "Table acdc.abba doesn't exist" or 
> something like that.
>  
> Example:
> {code:java}
> $ nodetool tablehistograms acdc.abba
> error: 
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
> -- StackTrace --
> javax.management.InstanceNotFoundException: 
> org.apache.cassandra.metrics:type=Table,keyspace=acdc,scope=abba,name=EstimatedPartitionSizeHistogram
>     at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
>     at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
>     at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1445)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:639)
>     at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
>     at sun.rmi.transport.Transport$1.run(Transport.java:200)
>     at sun.rmi.transport.Transport$1.run(Transport.java:197)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>     at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     at java.lang.Thread.run(Thread.java:745)
>     at 
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>     at 
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>     at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>     at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
>     at 
> javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown 
> Source)
>     at 
> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:903)
>     at 
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
>     at com.sun.proxy.$Proxy20.getValue(Unknown Source)
>     at 
> org.apache.cassandra.tools.NodeProbe.getColumnFamilyMetric(NodeProbe.java:1334)
>     at 
> org.apache.cassandra.tools.nodetool.TableHistograms.execute(TableHistograms.java:62)
>     at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:254)
>     at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:168){code}
>  



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

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



[jira] [Updated] (CASSANDRA-14098) Potential Integer Overflow

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14098:
-
Complexity: Low Hanging Fruit

> Potential Integer Overflow
> --
>
> Key: CASSANDRA-14098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14098
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: songwanging
>Priority: Low
>  Labels: lhf
> Attachments: 14098-3.0.txt
>
>
> Our tool DeepTect has detected a potential integer overflow: 
> Path: cassandra/src/java/org/apache/cassandra/service/StorageService.java
> {code:java}
> ...
> long totalRowCountEstimate = cfs.estimatedKeysForRange(range);
> ...
>  int splitCount = Math.max(1, Math.min(maxSplitCount, 
> (int)(totalRowCountEstimate / keysPerSplit)));
> {code}
> In the above code snippet, "totalRowCountEstimate" is a long variable, 
> "keysPerSplit" is an integer variable. If "totalRowCountEstimate" is super 
> large, directly casting "(totalRowCountEstimate / keysPerSplit" into integer 
> will definitely lead to a potential integer overflow.



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

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



[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11537:
-
Complexity: Low Hanging Fruit

> Give clear error when certain nodetool commands are issued before server is 
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Priority: Low
>  Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more 
> clear message when I issue a nodetool command that the server is not ready 
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool 
> scrub/compact/updatess etc you get unfriendly assertion. An exception would 
> be easier to understand. Also if a user has turned assertions off it is 
> unclear what might happen. 
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process. 
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at 
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at 
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at 
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1: 
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1



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

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



[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-10023:
-
Complexity: Low Hanging Fruit

> Emit a metric for number of local read and write calls
> --
>
> Key: CASSANDRA-10023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10023
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: sankalp kohli
>Assignee: Damien Stevenson
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Fix For: 4.x
>
> Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, 
> CASSANDRA-10023.patch
>
>
> Many C* drivers have feature to be replica aware and chose the co-ordinator 
> which is a replica. We should add a metric which tells us whether all calls 
> to the co-ordinator are replica aware.
> We have seen issues where client thinks they are replica aware when they 
> forget to add routing key at various places in the code. 



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

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



[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-9191:

Complexity: Low Hanging Fruit

> Log and count failure to obtain requested consistency
> -
>
> Key: CASSANDRA-9191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9191
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Observability
>Reporter: Matt Stump
>Priority: Low
>  Labels: lhf
> Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3
>
>
> Cassandra should have a way to log failed requests due to failure to obtain 
> requested consistency. This should be logged as error or warning by default. 
> Also exposed should be a counter for the benefit of opscenter. 
> Currently the only way to log this is at the client. Often the application 
> and DB teams are separate and it's very difficult to obtain client logs. Also 
> because it's only visible to the client no visibility is given to opscenter 
> making it difficult for the field to track down or isolate systematic or node 
> level errors.



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

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



[jira] [Updated] (CASSANDRA-11695) Move JMX connection config to cassandra.yaml

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11695:
-
Complexity: Low Hanging Fruit

> Move JMX connection config to cassandra.yaml
> 
>
> Key: CASSANDRA-11695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11695
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Zhongxiang Zheng
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
>
> Since CASSANDRA-10091, we always construct the JMX connector server 
> programatically, so we could move its configuration from cassandra-env to 
> yaml.



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

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



[jira] [Updated] (CASSANDRA-8969) Add indication in cassandra.yaml that rpc timeouts going too high will cause memory build up

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8969:

Complexity: Low Hanging Fruit

> Add indication in cassandra.yaml that rpc timeouts going too high will cause 
> memory build up
> 
>
> Key: CASSANDRA-8969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8969
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
> Attachments: 8969.txt
>
>
> It would be helpful to communicate that setting the rpc timeouts too high may 
> cause memory problems on the server as it can become overloaded and has to 
> retain the in flight requests in memory.  I'll get this done but just adding 
> the ticket as a placeholder for memory.



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

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



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

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13855:
-
Complexity: Low Hanging Fruit

> URL Seed provider
> -
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt
>
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1 
> line per seed, would be useful.



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

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



[jira] [Updated] (CASSANDRA-14566) Cache CSM.onlyPurgeRepairedTombstones()

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14566:
-
Complexity: Low Hanging Fruit

> Cache CSM.onlyPurgeRepairedTombstones()
> ---
>
> Key: CASSANDRA-14566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14566
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Thomas Pouget-Abadie
>Priority: Low
>  Labels: lhf, performance
> Attachments: 14566-3.11.txt
>
>
> We currently call {{CompactionStrategyManager.onlyPurgeRepairedTombstones()}} 
> *a lot* during compaction, I think at least for every key. So we should 
> probably cache the value, instead of constantly reading from a volatile and 
> calling parseBoolean.



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

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



[jira] [Updated] (CASSANDRA-14218) Deprecate Throwables.propagate usage

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14218:
-
Complexity: Low Hanging Fruit

> Deprecate Throwables.propagate usage
> 
>
> Key: CASSANDRA-14218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14218
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Romain Hardouin
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 14218-trunk.txt, 14218-trunk.txt
>
>
> Google decided to deprecate guava {{Throwables.propagate}} method:
>  * [Why we deprecated 
> Throwables.propagate|https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate]
>  * [Documentation 
> update|https://github.com/google/guava/wiki/ThrowablesExplained/_compare/92190ee7e37d334fa5fcdb6db8d0f43a2fdf02e1...226a3060445716d479981e606f589c99eee517ca]
> We have 35 occurences in the trunk:
> {code:java}
> $ rg -c 'Throwables.propagate' *
> src/java/org/apache/cassandra/streaming/StreamReader.java:1
> src/java/org/apache/cassandra/streaming/StreamTransferTask.java:1
> src/java/org/apache/cassandra/db/SnapshotDetailsTabularData.java:1
> src/java/org/apache/cassandra/db/Memtable.java:1
> src/java/org/apache/cassandra/db/ColumnFamilyStore.java:4
> src/java/org/apache/cassandra/cache/ChunkCache.java:2
> src/java/org/apache/cassandra/utils/WrappedRunnable.java:1
> src/java/org/apache/cassandra/hints/Hint.java:1
> src/java/org/apache/cassandra/tools/LoaderOptions.java:1
> src/java/org/apache/cassandra/tools/SSTableOfflineRelevel.java:1
> src/java/org/apache/cassandra/streaming/management/ProgressInfoCompositeData.java:3
> src/java/org/apache/cassandra/streaming/management/StreamStateCompositeData.java:2
> src/java/org/apache/cassandra/streaming/management/StreamSummaryCompositeData.java:2
> src/java/org/apache/cassandra/streaming/compress/CompressedStreamReader.java:1
> src/java/org/apache/cassandra/db/compaction/Scrubber.java:1
> src/java/org/apache/cassandra/db/compaction/Verifier.java:1
> src/java/org/apache/cassandra/db/compaction/CompactionHistoryTabularData.java:1
> src/java/org/apache/cassandra/db/compaction/Upgrader.java:1
> src/java/org/apache/cassandra/io/compress/CompressionMetadata.java:1
> src/java/org/apache/cassandra/streaming/management/SessionCompleteEventCompositeData.java:2
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleWriter.java:1
> src/java/org/apache/cassandra/io/sstable/ISSTableScanner.java:1
> src/java/org/apache/cassandra/streaming/management/SessionInfoCompositeData.java:3
> src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java:1
> {code}
> I don't know if we want to remove all usages but we should at least check 
> author's intention for each usage and refactor if needed.



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

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



[jira] [Updated] (CASSANDRA-13685) PartitionColumns.java:161: java.lang.AssertionError: null

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13685:
-
Complexity: Low Hanging Fruit

> PartitionColumns.java:161: java.lang.AssertionError: null
> -
>
> Key: CASSANDRA-13685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13685
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Legacy/Local Write-Read Paths
>Reporter: Jay Zhuang
>Assignee: Michael Burman
>Priority: Low
>  Labels: lhf
> Attachments: CASSANDRA-13685.patch
>
>
> Similar to CASSANDRA-8192, I guess the SSTable is corrupted:
> {noformat}
> ERROR [SSTableBatchOpen:1] 2017-07-10 21:28:09,325 CassandraDaemon.java:207 - 
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:339)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:486)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.io.sstable.format.SSTableReader$4.run(SSTableReader.java:534)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {noformat}
> Would be better to report {{CorruptSSTableException}} with SSTable path.



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

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



[jira] [Updated] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache size = 0

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13874:
-
Complexity: Low Hanging Fruit

> nodetool setcachecapacity behaves oddly when cache size = 0
> ---
>
> Key: CASSANDRA-13874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13874
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core, Local/Config
>Reporter: Jon Haddad
>Assignee: Michal Szczepanski
>Priority: Low
>  Labels: lhf, user-experience
> Attachments: 13874-trunk.txt
>
>
> If a node has row cache disabled, trying to turn it on via setcachecapacity 
> doesn't issue an error, and doesn't turn it on, it just silently doesn't work.



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

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



[jira] [Updated] (CASSANDRA-14787) nodetool status "Load" columns has wrong width

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14787:
-
Complexity: Low Hanging Fruit

> nodetool status "Load" columns has wrong width
> --
>
> Key: CASSANDRA-14787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14787
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Lapo Luchini
>Assignee: Kirk True
>Priority: Low
>  Labels: lhf, nodetool, pull-request-available
> Fix For: 4.x
>
> Attachments: CASSANDRA-14787.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Using Cassandra 3.11.2 on FreeBSD, I get:
> {code:java}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  AddressLoad   Tokens   Owns (effective)  Host ID ...
> UN  server1.andxor.it  11.11 MiB  256  39.6% ...
> UN  server2.andxor.it  32.04 MiB  256  41.8% ...
> UN  server3.andxor.it  519.33 KiB  256  40.0% ...
> UN  server4.andxor.it  10.95 MiB  256  40.3% ...
> UN  server5.andxor.it  11.03 MiB  256  38.4% ...
> {code}
> AFAICT this is caused by {{"%-9s"}} in 
> [Status.java:292|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/tools/nodetool/Status.java#L292]
>  which should be probably a 10 instead of 9.



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

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



[jira] [Updated] (CASSANDRA-10273) Reduce number of data directory scans during startup

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-10273:
-
Complexity: Low Hanging Fruit

> Reduce number of data directory scans during startup
> 
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Robert Stupp
>Assignee: Shaurya Gupta
>Priority: Low
>  Labels: lhf
> Attachments: patch_CASSANDRA-10273_trunk
>
>
> ATM we scan each data directory four times. We could easily reduce that to at 
> least two, maybe to one.
> # pre-flight (startup tests) scrub
> # pre-flight (startup tests) sstable min version
> # {{ColumnFamilyStore.createColumnFamilyStore}}
> # {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be 
> combined, as both appear at pretty related code paths.



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

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



[jira] [Updated] (CASSANDRA-14563) Add animalsniffer to build to ensure runtime jdk compatbility

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14563:
-
Complexity: Low Hanging Fruit

> Add animalsniffer to build to ensure runtime jdk compatbility
> -
>
> Key: CASSANDRA-14563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14563
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: mck
>Assignee: Sumanth Pasupuleti
>Priority: Low
>  Labels: lhf
>
> Cassandra-2.2 still supports running on JDK1.7
> No tests check this though, as all build and test with JDK1.8
> Adding the ant animalsniffer task can check that jdk1.8 classes or methods 
> are not used accidentally.
> ref: http://www.mojohaus.org/animal-sniffer/animal-sniffer/index.html



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

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



[jira] [Updated] (CASSANDRA-14228) Add expiration date overflow notice and recovery instructions to doc

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14228:
-
Complexity: Low Hanging Fruit

> Add expiration date overflow notice and recovery instructions to doc
> 
>
> Key: CASSANDRA-14228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14228
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Paulo Motta
>Assignee: Andrew Baker
>Priority: Low
>  Labels: lhf
>
> On CASSANDRA-14092 we added a new 
> [CASSANDRA-14092.txt|https://github.com/apache/cassandra/blob/trunk/CASSANDRA-14092.txt]
>  file with the maximum ttl expiration notice and recovery instructions for 
> affected users.
> We should probably also add the contents of this file to the documentation 
> with some basic formatting.



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

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



[jira] [Updated] (CASSANDRA-12464) Investigate the potential improvement of parallelism on higher level compactions in LCS

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12464:
-
Complexity: Low Hanging Fruit

> Investigate the potential improvement of parallelism on higher level 
> compactions in LCS
> ---
>
> Key: CASSANDRA-12464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12464
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Wei Deng
>Assignee: Pramod K Sivaraju
>Priority: Normal
>  Labels: lcs, lhf, performance
>
> According to LevelDB's design doc 
> [here|https://github.com/google/leveldb/blob/master/doc/impl.md#compactions], 
> "A compaction merges the contents of the picked files to produce a sequence 
> of level-(L+1) files", it will "switch to producing a new level-(L+1) file 
> after the current output file has reached the target file size" (in our case 
> 160MB), it will also "switch to a new output file when the key range of the 
> current output file has grown enough to overlap more than ten level-(L+2) 
> files". This is to ensure "that a later compaction of a level-(L+1) file will 
> not pick up too much data from level-(L+2)."
> Our current code in LeveledCompactionStrategy doesn't implement this last 
> rule, but we might be able to quickly implement it and see how much a 
> compaction throughput improvement it can deliver. Potentially we can create a 
> scenario where a number of large L0 SSTables are present (e.g. 200GB after 
> switching from STCS) and let it to create thousands of L1 SSTables overflow, 
> and see how fast LCS can digest this much data from L1 and properly 
> upper-level them to completion.



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

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



[jira] [Updated] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13010:
-
Complexity: Low Hanging Fruit

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Alex Lourie
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested, lhf
> Attachments: cleanup.png, multiple operations.png
>
>




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

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



[jira] [Updated] (CASSANDRA-13016) log messages should include human readable sizes

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13016:
-
Complexity: Low Hanging Fruit

> log messages should include human readable sizes
> 
>
> Key: CASSANDRA-13016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13016
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Jon Haddad
>Assignee: Sumant Sahney
>Priority: Normal
>  Labels: lhf
>
> displaying bytes by itself is difficult to read when going through log 
> messages.  we should add a human readable version in parens (10MB) after 
> displaying bytes.



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

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



[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12937:
-
Complexity: Low Hanging Fruit

> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: mck
>Assignee: Vinay Chella
>Priority: Low
>  Labels: lhf
>
> In many situations the choice of compression for sstables is more relevant to 
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable 
> compression that new tables will inherit (instead of the defaults found in 
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly 
> compression (btrfs, zfs) or specific disk configurations or even specific C* 
> versions (see CASSANDRA-10995 ).



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

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



[jira] [Updated] (CASSANDRA-11370) Display sstable count per level according to repair status on nodetool tablestats

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11370:
-
Complexity: Low Hanging Fruit

> Display sstable count per level according to repair status on nodetool 
> tablestats
> -
>
> Key: CASSANDRA-11370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11370
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> After CASSANDRA-8004 we still display sstables in each level on nodetool 
> tablestats as if we had a single compaction strategy, while we have one 
> strategy for repaired and another for unrepaired data. 
> We should split display into repaired and unrepaired set, so this:
> SSTables in each level: [2, 20/10, 15, 0, 0, 0, 0, 0, 0]
> Would become:
> SSTables in each level (repaired): [1, 10, 0, 0, 0, 0, 0, 0, 0]
> SSTables in each level (unrepaired): [1, 10, 15, 0, 0, 0, 0, 0, 0]



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

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



[jira] [Updated] (CASSANDRA-12881) Move SASI docs into sphinx docs

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12881:
-
Complexity: Low Hanging Fruit

> Move SASI docs into sphinx docs
> ---
>
> Key: CASSANDRA-12881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12881
> Project: Cassandra
>  Issue Type: Task
>  Components: Legacy/Documentation and Website
>Reporter: Evan Prothro
>Priority: Low
>  Labels: lhf, sasi
>
> Previous TODO in code regarding SASI docs:
> TODO: we should probably move the first half of that documentation to the 
> general documentation, and the implementation explanation parts into the wiki.



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

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



[jira] [Updated] (CASSANDRA-14476) ShortType and ByteType are incorrectly considered variable-length types

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14476:
-
Complexity: Low Hanging Fruit

> ShortType and ByteType are incorrectly considered variable-length types
> ---
>
> Key: CASSANDRA-14476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14476
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Core
>Reporter: Vladimir Krivopalov
>Assignee: Jearvon Dharrie
>Priority: Low
>  Labels: lhf
>
> The AbstractType class has a method valueLengthIfFixed() that returns -1 for 
> data types with a variable length and a positive value for types with a fixed 
> length. This is primarily used for efficient serialization and 
> deserialization. 
>  
> It turns out that there is an inconsistency in types ShortType and ByteType 
> as those are in fact fixed-length types (2 bytes and 1 byte, respectively) 
> but they don't have the valueLengthIfFixed() method overloaded and it returns 
> -1 as if they were of variable length.
>  
> It would be good to fix that at some appropriate point, for example, when 
> introducing a new version of SSTables format, to keep the meaning of the 
> function consistent across data types. Saving some bytes in serialized format 
> is a minor but pleasant bonus.



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

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



[jira] [Updated] (CASSANDRA-12001) nodetool stopdaemon doesn't stop cassandra gracefully

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12001:
-
Complexity: Low Hanging Fruit

> nodetool stopdaemon  doesn't  stop cassandra gracefully 
> 
>
> Key: CASSANDRA-12001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12001
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
> Environment: Ubuntu: Linux  3.11.0-15-generic #25~precise1-Ubuntu SMP 
> Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Cassandra Version : 
> cassandra -v
> 2.1.2
>Reporter: Anshu Vajpayee
>Priority: Low
>  Labels: lhf
>
> As per general opinion, nodetool stopdaemon should perform graceful shutdown 
> rater than crash killing of cassandra daemon .
> It  doesn't flush the memtables and also it doesn't stop the thrift and CQL 
> connection interfaces before crashing/stopping  the node.  It directly calls 
> SIGTERM on process as simple as kill -15/ctrl + c. 
>  
> 1. created a table  like as below:
> cqlsh:test_ks> create table t2(id1 int, id2 text, primary key(id1));
> cqlsh:test_ks> 
> cqlsh:test_ks> insert into t2(id1,id2) values (1,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (2,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (3,'a');
> cqlsh:test_ks> select * from t2;
>  id1 | id2
> -+-
>1 |   a
>2 |   a
>3 |   a
> 2.Flush  the memtable manually using nodetool flush
> student@cascor:~/node1/apache-cassandra-2.1.2/bin$ nodetool flush
> student@cascor:~/node1/apache-cassandra-2.1.2/bin$ cd 
> ../data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d/
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  ls -ltr 
> total 36
> -rw-rw-r-- 1 student student   16 Jun 13 12:14 test_ks-t2-ka-1-Filter.db
> -rw-rw-r-- 1 student student   54 Jun 13 12:14 test_ks-t2-ka-1-Index.db
> -rw-rw-r-- 1 student student   93 Jun 13 12:14 test_ks-t2-ka-1-Data.db
> -rw-rw-r-- 1 student student   91 Jun 13 12:14 test_ks-t2-ka-1-TOC.txt
> -rw-rw-r-- 1 student student   80 Jun 13 12:14 test_ks-t2-ka-1-Summary.db
> -rw-rw-r-- 1 student student 4442 Jun 13 12:14 test_ks-t2-ka-1-Statistics.db
> -rw-rw-r-- 1 student student   10 Jun 13 12:14 test_ks-t2-ka-1-Digest.sha1
> -rw-rw-r-- 1 student student   43 Jun 13 12:14 
> test_ks-t2-ka-1-CompressionInfo.db
> 3. Make few more changes on table t2
> cqlsh:test_ks> insert into t2(id1,id2) values (5,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (6,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (7,'a');
> cqlsh:test_ks> insert into t2(id1,id2) values (8,'a');
> cqlsh:test_ks> select * from t2;
>  id1 | id2
> -+-
>5 |   a
>1 |   a
>8 |   a
>2 |   a
>7 |   a
>6 |   a
>3 |   a
> 4. Stopping the node using nodetool stopdaemon 
> student@cascor:~$ nodetool stopdaemon
> Cassandra has shutdown.
> error: Connection refused
> -- StackTrace --
> java.net.ConnectException: Connection refused
> 5. No new version of SStables . Reason stopdaemon doesn't run nodetool 
> flush/drain before actually stopping daemon.
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  ls -ltr
> total 36
> -rw-rw-r-- 1 student student   16 Jun 13 12:14 test_ks-t2-ka-1-Filter.db
> -rw-rw-r-- 1 student student   54 Jun 13 12:14 test_ks-t2-ka-1-Index.db
> -rw-rw-r-- 1 student student   93 Jun 13 12:14 test_ks-t2-ka-1-Data.db
> -rw-rw-r-- 1 student student   91 Jun 13 12:14 test_ks-t2-ka-1-TOC.txt
> -rw-rw-r-- 1 student student   80 Jun 13 12:14 test_ks-t2-ka-1-Summary.db
> -rw-rw-r-- 1 student student 4442 Jun 13 12:14 test_ks-t2-ka-1-Statistics.db
> -rw-rw-r-- 1 student student   10 Jun 13 12:14 test_ks-t2-ka-1-Digest.sha1
> -rw-rw-r-- 1 student student   43 Jun 13 12:14 
> test_ks-t2-ka-1-CompressionInfo.db
> student@cascor:~/node1/apache-cassandra-2.1.2/data/data/test_ks/t2-a671f6b0319a11e6a91ae3263299699d$
>  



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

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



[jira] [Updated] (CASSANDRA-11141) Alert if firewall is running and/or blocking C* ports

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11141:
-
Complexity: Low Hanging Fruit

> Alert if firewall is running and/or blocking C* ports
> -
>
> Key: CASSANDRA-11141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11141
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> We've struggled quite a few times with firewalls blocking C* port on Windows. 
> [~JoshuaMcKenzie] suggested on CASSANDRA-11073:
> bq. It'd be nice if there's a way for us to check whether or not firewalls 
> are running on Windows and fire an alert if found (or if C* ports are blocked 
> in built-in firewall, for instance).



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

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



[jira] [Updated] (CASSANDRA-11097) Idle session timeout for secure environments

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11097:
-
Complexity: Low Hanging Fruit

> Idle session timeout for secure environments
> 
>
> Key: CASSANDRA-11097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11097
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/CQL
>Reporter: Jeff Jirsa
>Priority: Low
>  Labels: lhf, ponies
>
> A thread on the user list pointed out that some use cases may prefer to have 
> a database disconnect sessions after some idle timeout. An example would be 
> an administrator who connected via ssh+cqlsh and then walked away. 
> Disconnecting that user and forcing it to re-authenticate could protect 
> against unauthorized access.
> It seems like it may be possible to do this using a netty 
> {{IdleStateHandler}} in a way that's low risk and perhaps off by default.  



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

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



[jira] [Updated] (CASSANDRA-13356) BootstrapMonitor.progress does not store all error messages

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13356:
-
Complexity: Low Hanging Fruit

> BootstrapMonitor.progress does not store all error messages
> ---
>
> Key: CASSANDRA-13356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13356
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Tools
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The BootstrapMonitor.progress ignores error messages when an error is 
> ProgressEventType.ERROR. Indeed, RepairRunner.progress once had a similar 
> bug, but is fixed. The fixed code is:
> {code}
>  public void progress(String tag, ProgressEvent event)
> {
> ProgressEventType type = event.getType();
> String message = String.format("[%s] %s", 
> format.format(System.currentTimeMillis()), event.getMessage());
> if (type == ProgressEventType.PROGRESS)
> {
> message = message + " (progress: " + 
> (int)event.getProgressPercentage() + "%)";
> }
> out.println(message);
> if (type == ProgressEventType.ERROR)
> {
> error = new RuntimeException("Repair job has failed with the 
> error message: " + message);
> }
> if (type == ProgressEventType.COMPLETE)
> {
> condition.signalAll();
> }
> }
> {code}
> Please refer to CASSANDRA-12508 for details.



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

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



[jira] [Updated] (CASSANDRA-11714) shutdown script should wait more than 30 seconds before force kill

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11714:
-
Complexity: Low Hanging Fruit

> shutdown script should wait more than 30 seconds before force kill
> --
>
> Key: CASSANDRA-11714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11714
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Wei Deng
>Assignee: Wei Deng
>Priority: Low
>  Labels: lhf
>
> I'm running with 3.0.6 and it appears that if I let it run for multiple days 
> (ingesting a never-ending streaming data from Kafka), then the next time I'm 
> restarting the JVM by "service cassandra restart", it will take 9 minutes to 
> replay the commit log segments (the commitlog_total_space_in_mb is using the 
> default 8GB and I observed close to 8GB commitlog segment files before the 
> restart). Here is a fragment of the system.log showing how long it takes:
> {noformat}
> INFO  [main] 2016-05-04 19:06:54,356  CommitLog.java:168 - Replaying 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248187.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248191.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248195.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248198.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248201.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248205.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248209.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248213.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248217.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248221.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248225.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248230.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248234.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248238.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248242.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248246.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248250.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248254.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248258.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248262.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248266.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248270.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248274.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248278.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248282.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248286.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248290.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248294.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248299.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248303.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248307.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248311.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248315.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248319.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248323.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248327.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248331.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248335.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248340.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248344.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248348.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248352.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248356.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248360.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248364.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248368.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248372.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248376.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248380.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248384.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248388.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248392.log, 
> /mnt/ephemeral/cassandra/commitlog/CommitLog-6-1462146248396.log, 
> 

[jira] [Updated] (CASSANDRA-3017) add a Message size limit

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-3017:

Complexity: Low Hanging Fruit

> add a Message size limit
> 
>
> Key: CASSANDRA-3017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3017
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Streaming and Messaging
>Reporter: Jonathan Ellis
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: 
> 0001-use-the-thrift-max-message-size-for-inter-node-messa.patch, 
> trunk-3017.txt
>
>
> We protect the server from allocating huge buffers for malformed message with 
> the Thrift frame size (CASSANDRA-475).  But we don't have similar protection 
> for the inter-node Message objects.
> Adding this would be good to deal with malicious adversaries as well as a 
> malfunctioning cluster participant.



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

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



[jira] [Updated] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13990:
-
Complexity: Low Hanging Fruit

> Remove OldNetworkTopologyStrategy
> -
>
> Key: CASSANDRA-13990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13990
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Jeremy Hanna
>Priority: Low
>  Labels: lhf
>
> RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 
> (CASSANDRA-1392) and it's still around.  Is there any reason to keep this 
> relatively dead code in the codebase at this point?  I'm not aware of its use 
> and it sometimes confuses users.



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

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



[jira] [Updated] (CASSANDRA-14810) Upgrade dtests to pytest-3.8

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-14810:
-
Complexity: Low Hanging Fruit

> Upgrade dtests to pytest-3.8
> 
>
> Key: CASSANDRA-14810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14810
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: Stefan Podkowinski
>Assignee: Thomas Pouget-Abadie
>Priority: Low
>  Labels: lhf
> Attachments: 14810-master.txt
>
>
> The [dtest project|https://github.com/apache/cassandra-dtest] uses pytest as 
> test runner of choice for executing tests on builds.apache.org or CircleCI. 
> The pytest dependency has recently been upgrade to 3.6, but couldn't be 
> upgrade to the most recent 3.8 version, due to issues described below.
> Before test execution, the {{run_dtests.py}} script will gather a list of all 
> tests:
>  {{./run_dtests.py --dtest-print-tests-only}}
> Afterwards pytest can be started with any of the output lines as argument. 
> With pytest-3.8 however, the output format changed and preventing pytest to 
> find the test:
>  {{pytest 
> upgrade_tests/upgrade_supercolumns_test.py::TestSCUpgrade::test_upgrade_super_columns_through_limited_versions}}
>  vs
>  {{pytest 
> upgrade_supercolumns_test.py::TestSCUpgrade::test_upgrade_super_columns_through_limited_versions}}
> The underlying issue appears to be the changes in the {{pytest 
> --collect-only}} output, consumed in {{run_dtests.py}}, which now includes a 
>  element that needs to be parsed as well to derive at the path as we 
> did before. We'd have to parse the new output and assemble the correct paths 
> again, so we can use run_dtests.py as we did before with pytest 3.6.



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

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



[jira] [Updated] (CASSANDRA-5780) nodetool status and ring report incorrect/stale information after decommission

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-5780:

Complexity: Low Hanging Fruit

> nodetool status and ring report incorrect/stale information after decommission
> --
>
> Key: CASSANDRA-5780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5780
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Peter Haggerty
>Assignee: John Sumsion
>Priority: Low
>  Labels: lhf, ponies, qa-resolved
> Fix For: 2.1.x
>
>
> Cassandra 1.2.6 ring of 12 instances, each with 256 tokens.
> Decommission 3 of the 12 nodes, one after another resulting a 9 instance ring.
> The 9 instances of cassandra that are in the ring all correctly report 
> nodetool status information for the ring and have the same data.
> After the first node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> "nodetool status" on "decommissioned-3rd" reports 9 nodes
> The storage load information is similarly stale on the various decommissioned 
> nodes. The nodetool status and ring commands continue to return information 
> as if they were part of a cluster and they appear to return the last 
> information that they saw.
> In contrast the nodetool info command fails with an exception, which isn't 
> ideal but at least indicates that there was a failure rather than returning 
> stale information.



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

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



[jira] [Updated] (CASSANDRA-8817) Error handling in Cassandra logs in low memory scenarios could use improvement

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8817:

Complexity: Low Hanging Fruit

> Error handling in Cassandra logs in low memory scenarios could use improvement
> --
>
> Key: CASSANDRA-8817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8817
> Project: Cassandra
>  Issue Type: Improvement
> Environment: Ubuntu 14.04, VM originally created with 1 GB RAM, DSE 
> 4.6.0 installed
>Reporter: Michael DeHaan
>Priority: Low
>  Labels: lhf
> Fix For: 2.1.x
>
>
> When running Cassandra with a low amount of RAM, in this case, using DataStax 
> Enterprise 4.6.0 in a reasonably default configuration, I find that I get an 
> error after starting and trying to use nodetool, namely that it cannot 
> connect to 127.0.0.1.   Originally this sends me up a creek, looking for why 
> Cassandra is not listening on 7199.  The truth ends up being a bit more 
> cryptic - that Cassandra isn't running.
> Upon looking at the Cassandra system logs, I see the last thing that it did 
> was print out the (very long) class path.   This confused me as basically I'm 
> seeing no errors in the log at all.
> I am proposing that Cassandra should check the amount of available RAM and 
> issue a warning in the log, or possibly an error, because in this scenario 
> Cassandra is going to oomkill and probably could have predicted this in 
> advance.
> Something like:
> "Found X MB of RAM, expecting at least Y MB of RAM, Z MB recommended, may 
> crash, adjust " or something similar would be a possible solution.



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

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



[jira] [Updated] (CASSANDRA-8937) add liveSSTableCount metrics at keyspace level

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8937:

Complexity: Low Hanging Fruit

> add liveSSTableCount metrics at keyspace level
> --
>
> Key: CASSANDRA-8937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8937
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: yangwei
>Assignee: yangwei
>Priority: Low
>  Labels: lhf
> Fix For: 2.1.x
>
> Attachments: 
> 0001-add-liveSSTableCount-metrics-at-keyspace-level-2.1.patch, 
> 0001-add-liveSSTableCount-metrics-at-keyspace-level.patch
>
>
> We currently don't have liveSSTableCount metrics aggregated at keyspace 
> level.  If many sstables exists and we can't realize it earlier,  cassandra 
> will oom while doing scanning operations. It would be nice and easy to 
> aggregate it.



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

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



[jira] [Updated] (CASSANDRA-11888) cassandra-env.sh may not work properly with jvm args containing a space

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11888:
-
Complexity: Low Hanging Fruit

> cassandra-env.sh may not work properly with jvm args containing a space
> ---
>
> Key: CASSANDRA-11888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11888
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
> Environment: linux
>Reporter: Russ Hatch
>Priority: Low
>  Labels: lhf
>
> When using the JVM_EXTRA_OPTS environment variable, it looks like there's 
> some cases that may not work if an env var contains a space.
> For example, setting:
> {noformat}
> export JVM_EXTRA_OPTS='-XX:OnOutOfMemoryError="echo oh_no"'
> {noformat}
> Results in the jvm not starting because the resultant startup command looks 
> to java like it should load a class called oh_no.
> {noformat}
> Error: Could not find or load main class oh_no
> {noformat}
> I think this results from the last line of cassandra-env.sh, where it does 
> this:
> {noformat}
> JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
> {noformat}



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

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



[jira] [Updated] (CASSANDRA-12485) Always require replace_address to replace existing token

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12485:
-
Complexity: Low Hanging Fruit

> Always require replace_address to replace existing token
> 
>
> Key: CASSANDRA-12485
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12485
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Distributed Metadata
>Reporter: Paulo Motta
>Priority: Low
>  Labels: lhf
>
> CASSANDRA-10134 prevented replace an existing node unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified.
> We should extend this behavior to tokens, preventing a node from joining the 
> ring if another node with the same token already existing in the ring, unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified in order to avoid 
> catastrophic scenarios.
> One scenario where this can easily happen is if you replace a node with 
> another node with a different IP, and after some time you restart the 
> original node by mistake. The original node will then take over the tokens of 
> the replaced node (since it has a newer gossip generation).



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

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



[jira] [Updated] (CASSANDRA-13979) update contributing guidelines

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13979:
-
Complexity: Low Hanging Fruit

> update contributing guidelines
> --
>
> Key: CASSANDRA-13979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13979
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
>  Labels: lhf
>
> Current contributing guidelines point to the more or less dead wiki, we 
> should point to the website docs.



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

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



[jira] [Updated] (CASSANDRA-13960) update cassandra.yaml links to point to new docs instead of the wiki

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13960:
-
Complexity: Low Hanging Fruit

> update cassandra.yaml links to point to new docs instead of the wiki
> 
>
> Key: CASSANDRA-13960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Gabriel Nobrega
>Priority: Low
>  Labels: lhf
>
> The wiki is dead, let's clean up the links and be sure we have the right into 
> on cassandra.apache.org.
> {code}
> # NOTE:
> #   See http://wiki.apache.org/cassandra/StorageConfiguration for
> #   full explanations of configuration directives
> # /NOTE
> {code}



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

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



[jira] [Updated] (CASSANDRA-4967) config options have different bounds when set via different methods

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-4967:

Complexity: Low Hanging Fruit

> config options have different bounds when set via different methods
> ---
>
> Key: CASSANDRA-4967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4967
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Affects Versions: 1.2.0 beta 2
>Reporter: Robert Coli
>Priority: Low
>  Labels: lhf
>
> (similar to some of the work done in 
> https://issues.apache.org/jira/browse/CASSANDRA-4479
> )
> If one sets a value in cassandra.yaml, that value might be subject to bounds 
> checking there. However if one sets that same value via JMX, it doesn't get 
> set via a bounds-checking code path.
> "./src/java/org/apache/cassandra/config/DatabaseDescriptor.java" (JMX set)
> {noformat}
> public static void setPhiConvictThreshold(double phiConvictThreshold)
> {
> conf.phi_convict_threshold = phiConvictThreshold;
> }
> {noformat}
> Versus..
> ./src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
> (cassandra.yaml)
> {noformat}
> static void loadYaml()
> ...
>   /* phi convict threshold for FailureDetector */
> if (conf.phi_convict_threshold < 5 || conf.phi_convict_threshold 
> > 16)
> {
> throw new ConfigurationException("phi_convict_threshold must 
> be between 5 and 16");
> }
> {noformat}
> This seems to create a confusing situation where the range of potential 
> values for a given configuration option is different when set by different 
> methods. 
> It's difficult to imagine a circumstance where you want bounds checking to 
> keep your node from starting if you set that value in cassandra.yaml, but 
> also want to allow circumvention of that bounds checking if you set via JMX.



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

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



[jira] [Updated] (CASSANDRA-11409) set read repair chance to 0 but find read repair process in trace

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11409:
-
Complexity: Low Hanging Fruit

> set read repair chance to 0 but find read repair process in trace
> -
>
> Key: CASSANDRA-11409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11409
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL, Legacy/Distributed Metadata
> Environment: Cassandra 2.1.13 with centos 7
>Reporter: Ryan Cho
>Priority: Low
>  Labels: lhf
> Attachments: 螢幕快照 2016-03-23 下午2.06.10.png
>
>
> I have set  dclocal_read_repair_chance and read_repair_chance to 0.0 for one 
> month, but I still find "Read-repair DC_LOCAL" and "Initiating read-repair" 
> activities in system_trace.events, and  query was executed in these two days 
> and long time after set read repair chance to 0.0 



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

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



[jira] [Updated] (CASSANDRA-8880) Add metrics to monitor the amount of tombstones created

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8880:

Complexity: Low Hanging Fruit

> Add metrics to monitor the amount of tombstones created
> ---
>
> Key: CASSANDRA-8880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8880
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Michaël Figuière
>Priority: Low
>  Labels: lhf, metrics
> Fix For: 2.1.x
>
> Attachments: cassandra-2.1-8880.patch
>
>
> AFAIK there's currently no way to monitor the amount of tombstones created on 
> a Cassandra node. CASSANDRA-6057 has made it possible for users to figure out 
> how many tombstones are scanned at read time, but in write mostly workloads, 
> it may not be possible to realize if some inappropriate queries are 
> generating too many tombstones.
> Therefore the following additional metrics should be added:
> * {{writtenCells}}: amount of cells that have been written
> * {{writtenTombstoneCells}}: amount of tombstone cells that have been written
> Alternatively these could be exposed as a single gauge such as 
> {{writtenTombstoneCellsRatio}}.



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

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



[jira] [Updated] (CASSANDRA-13733) nodetool toptables

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13733:
-
Complexity: Low Hanging Fruit

> nodetool toptables
> --
>
> Key: CASSANDRA-13733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability, Observability/Metrics
>Reporter: Jon Haddad
>Assignee: Neil Patel
>Priority: Normal
>  Labels: lhf, low-hanging-fruit
>
> In the same way toppartitions samples the activity on a table, toptables 
> should be able to report which tables are used the most.



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

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



[jira] [Updated] (CASSANDRA-12489) consecutive repairs of same range always finds 'out of sync' in sane cluster

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12489:
-
Complexity: Low Hanging Fruit

> consecutive repairs of same range always finds 'out of sync' in sane cluster
> 
>
> Key: CASSANDRA-12489
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12489
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Benjamin Roth
>Assignee: Benjamin Roth
>Priority: Normal
>  Labels: lhf
> Attachments: trace_3_10.1.log.gz, trace_3_10.2.log.gz, 
> trace_3_10.3.log.gz, trace_3_10.4.log.gz, trace_3_9.1.log.gz, 
> trace_3_9.2.log.gz
>
>
> No matter how often or when I run the same subrange repair, it ALWAYS tells 
> me that some ranges are our of sync. Tested in 3.9 + 3.10 (git trunk of 
> 2016-08-17). The cluster is sane. All nodes are up, cluster is not overloaded.
> I guess this is not a desired behaviour. I'd expect that a repair does what 
> it says and a consecutive repair shouldn't report "out of syncs" any more if 
> the cluster is sane.
> Especially for tables with MVs that puts a lot of pressure during repair as 
> ranges are repaired over and over again.
> See traces of different runs attached.



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

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



[jira] [Updated] (CASSANDRA-13947) Add some clarifying examples of nodetool usage

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13947:
-
Complexity: Low Hanging Fruit

> Add some clarifying examples of nodetool usage
> --
>
> Key: CASSANDRA-13947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13947
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/nodetool
>Reporter: Jeremy Hanna
>Priority: Normal
>  Labels: lhf
>
> Certain nodetool commands would benefit from some examples of usage.  For 
> example, user defined compactions require a comma separated list of path 
> names from the data directory room to the table name.
> {code}
> nodetool compact --user-defined 
> system_schema/types-5a8b1ca866023f77a0459273d308917a/mc-5-big-Data.db,system_schema/types-5a8b1ca866023f77a0459273d308917a/mc-6-big-Data.db
> {code}



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

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



[jira] [Updated] (CASSANDRA-13601) Changes requested to the cassandra's debian + rpm installers packages

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13601:
-
Complexity: Low Hanging Fruit

> Changes requested to the cassandra's debian + rpm installers packages
> -
>
> Key: CASSANDRA-13601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13601
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
> Environment: ~$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
>Reporter: Amitkumar Ghatwal
>Priority: Low
>  Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: ppc64le_unaligned_memory_access.patch
>
>
> Hi All,
> Thanks [~mshuler] for helping in installing cassandra using arch independent 
> installers  for debian + rpm packages from here : 
> http://cassandra.apache.org/download/
> For my architecture - " ppc64le" , the installation process from debian + rpm 
> wasn't straightforward. And needed below configuration level changes.
> For Ubuntu- Cassandra 3.10 release - below changes were needed
> 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x 
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list 
> 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> For RHEL - Cassandra 3.0.13 release - below changes were needed
> 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh
> 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in 
> (/usr/share/cassandra/lib)- Downloaded from here . 
> 4) Restart cassandra service
> Could you please help in introducing above changes so that cassandra can be 
> installed from the debian + rpm pcakages and will indeed become architecture 
> independent.
> Regards,
> Amit



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

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



[jira] [Updated] (CASSANDRA-12760) SELECT JSON "firstName" FROM ... results in {"\"firstName\"": "Bill"}

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12760:
-
Complexity: Low Hanging Fruit

> SELECT JSON "firstName" FROM ... results in {"\"firstName\"": "Bill"}
> -
>
> Key: CASSANDRA-12760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12760
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
> Environment: Cassandra 3.7
>Reporter: Niek Bartholomeus
>Assignee: Shivang Nagaria
>Priority: Normal
>  Labels: lhf
>
> I'm using Cassandra to store data coming from Spark and intended for being 
> consumed by a javascript front end.
> To avoid unnecessary field name mappings I have decided to use mixed case 
> fields in Cassandra. I also happily leave it to Cassandra to jsonify the data 
> (using SELECT JSON ...) so my scala/play web server can send the results from 
> Cassandra straight through to the front end.
> I noticed however that all mixed case fields (that were created with quotes 
> as Cassandra demands) end up having a double set of quotes
> {code}
> create table user(id text PRIMARY KEY, "firstName" text);
> insert into user(id, "firstName") values ('b', 'Bill');
> select json * from user;
>  [json]
> --
>  {"id": "b", "\"firstName\"": "Bill"}
> {code}
> Ideally that would be:
> {code}
>  [json]
> --
>  {"id": "b", "firstName": "Bill"}
> {code}
> I worked around it for now by removing all "\""'s before sending the json to 
> the front end.



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

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



[jira] [Updated] (CASSANDRA-13816) Document and test CAS and non-CAS batch behavior for deleting and inserting the same key

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13816:
-
Complexity: Low Hanging Fruit

> Document and test CAS and non-CAS batch behavior for deleting and inserting 
> the same key
> 
>
> Key: CASSANDRA-13816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13816
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Documentation and Website, Legacy/Testing
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Low
>  Labels: LWT, lhf
> Fix For: 3.11.x, 4.x
>
>
> Add/verify unit tests for inserting and deleting the same key for cell 
> deletion, partition deletion, and range tombstone deletion for both CAS and 
> non-CAS batches.
> Don't change the existing behavior.
> The behavior differs between batch and CAS so in the both the CAS and batch 
> documentation mention that the behavior is not consistent. Make sure it is 
> visible in both high level and reference docs for that functionality.



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

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



[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11402:
-
Complexity: Low Hanging Fruit

> Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
> 
>
> Key: CASSANDRA-11402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11402
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Nishant Kelkar
>Priority: Low
>  Labels: lhf
> Fix For: 3.11.x
>
> Attachments: 11402-3_5_patch1.patch, 11402-trunk.txt
>
>
> With the accompanying designation of which memtableflushwriter it is, this 
> threadpool name is too long for the hardcoded padding in tpstats output.
> We should dynamically calculate padding so that we don't need to check this 
> every time we add a threadpool.



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

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



[jira] [Updated] (CASSANDRA-10031) Name threads for improved ops/debugging

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-10031:
-
Complexity: Low Hanging Fruit

> Name threads for improved ops/debugging
> ---
>
> Key: CASSANDRA-10031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: T Jake Luciani
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> We currently provide basic names for threads in threads like {{STREAM-IN-1}}  
> which gives some basic information about what the job of the thread is.  
> When looking at a log statement or jstack it's helpful to have this context.
> For our work stealing thread pool we share threads across all thread pools so 
> we lose this insight.  
> I'd like to propose we start using the Thread.currentThread().setName("")
> In different aspects of the code to improve insight as to what cassandra is 
> doing at any given moment.
>* At a minimum in the start of each run() method.
>   Ideally for much finer grain things.
>* In compaction include the partition name currently being working on.  
>* In SP include the client ip
> Etc...



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

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



[jira] [Updated] (CASSANDRA-7276) Include keyspace and table names in logs where possible

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-7276:

Complexity: Low Hanging Fruit

> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Priority: Low
>  Labels: bootcamp, lhf
> Fix For: 2.1.x
>
> Attachments: 0001-Better-Logging-for-KS-and-CF.patch, 
> 0001-Consistent-KS-and-Table-Logging.patch, 
> 0001-Logging-KS-and-CF-consistently.patch, 
> 0001-Logging-for-Keyspace-and-Tables.patch, 2.1-CASSANDRA-7276-v1.txt, 
> cassandra-2.1-7276-compaction.txt, cassandra-2.1-7276.txt, 
> cassandra-2.1.9-7276-v2.txt, cassandra-2.1.9-7276.txt
>
>
> Most error messages and stacktraces give you no clue as to what keyspace or 
> table was causing the problem.  For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java 
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at 
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at 
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at 
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at 
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error 
> messages or logs whenever possible.  This includes reads, writes, 
> compactions, flushes, repairs, and probably more.



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

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



[jira] [Updated] (CASSANDRA-11516) Make max number of streams configurable

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11516:
-
Complexity: Low Hanging Fruit

> Make max number of streams configurable
> ---
>
> Key: CASSANDRA-11516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11516
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Streaming and Messaging, Local/Config
>Reporter: Sebastian Estevez
>Assignee: Giampaolo
>Priority: Normal
>  Labels: lhf
>
> Today we default to num cores. In large boxes (many cores), this is 
> suboptimal as it can generate huge amounts of garbage that GC can't keep up 
> with.
> Usually we tackle issues like this with the streaming throughput levers but 
> in this case the problem is CPU consumption by StreamReceiverTasks 
> specifically in the IntervalTree build -- 
> https://github.com/apache/cassandra/blob/cassandra-2.1.12/src/java/org/apache/cassandra/utils/IntervalTree.java#L257
> We need a max number of parallel streams lever to hanlde this.



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

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



[jira] [Updated] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-4938:

Complexity: Low Hanging Fruit

> CREATE INDEX can block for creation now that schema changes may be concurrent
> -
>
> Key: CASSANDRA-4938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4938
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Response from CREATE INDEX command comes faster than the creation of 
> secondary index. So below code:
> {code:xml}
> CREATE INDEX ON tab(name);
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> doesn't return any rows(of course, in column family "tab", there are some 
> records with "name" value = 'Chris'..) and any errors ( i would expect 
> something like ??"Bad Request: No indexed columns present in by-columns 
> clause with Equal operator"??) 
> Inputing some timeout between those two commands resolves the problem, so:
> {code:xml}
> CREATE INDEX ON tab(name);
> Sleep(timeout); // for column family with 2000 rows the timeout had to be set 
> for ~1 second 
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> will return all rows with values as specified.
> I'm using single node cluster.



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

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



[jira] [Updated] (CASSANDRA-11978) StreamReader fails to write sstable if CF directory is symlink

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11978:
-
Complexity: Low Hanging Fruit

> StreamReader fails to write sstable if CF directory is symlink
> --
>
> Key: CASSANDRA-11978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11978
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Michael Frisch
>Assignee: Kirk True
>Priority: Normal
>  Labels: lhf
>
> I'm using Cassandra v2.2.6.  If the CF is stored as a symlink in the keyspace 
> directory on disk then StreamReader.createWriter fails because 
> Descriptor.fromFilename is passed the actual path on disk instead of path 
> with the symlink.
> Example:
> /path/to/data/dir/Keyspace/CFName -> /path/to/data/dir/AnotherDisk/CFName
> Descriptor.fromFilename is passed "/path/to/data/dir/AnotherDisk/CFName" 
> instead of "/path/to/data/dir/Keyspace/CFName", then it concludes that the 
> keyspace name is "AnotherDisk" which is erroneous. I've temporarily worked 
> around this by using cfs.keyspace.getName() to get the keyspace name and 
> cfs.name to get the CF name as those are correct.



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

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



[jira] [Updated] (CASSANDRA-13890) Expose current compaction throughput

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13890:
-
Complexity: Low Hanging Fruit

> Expose current compaction throughput
> 
>
> Key: CASSANDRA-13890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13890
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Getting and setting the current compaction throughput limit is supported, but 
> there's no means of knowing if the setting is actually making a difference.
> Let's expose the current throughput being utilized by Cassandra that's in the 
> {{compactionRateLimiter}}



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

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



[jira] [Updated] (CASSANDRA-5108) expose overall progress of cleanup tasks in jmx

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-5108:

Complexity: Low Hanging Fruit

> expose overall progress of cleanup tasks in jmx
> ---
>
> Key: CASSANDRA-5108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5108
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Observability, Local/Compaction
>Affects Versions: 1.2.0
>Reporter: Michael Kjellman
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> it would be nice if, upon starting a cleanup operation, cassandra could 
> maintain a Set (i assume this already exists as we have to know which file to 
> act on next) and a new set of "completed" sstables. When each is compacted 
> remove it from the pending list. That way C* could give an overall completion 
> of the long running and pending cleanup tasks.



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

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



[jira] [Updated] (CASSANDRA-5992) Add a logger.trace call to Tracing

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-5992:

Complexity: Low Hanging Fruit

> Add a logger.trace call to Tracing
> --
>
> Key: CASSANDRA-5992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5992
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Observability
>Reporter: Jeremiah Jordan
>Assignee: Ryan Magnusson
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
> Attachments: CASSANDRA-5992.txt
>
>
> A bunch of stuff is now written to Tracing, and there are no logging trace 
> calls any more.  If a node is having issues on the read/write path and 
> tracing can't actually save data, there is no way to see through logging what 
> is going on.  Would be nice if we made all Tracing messages also go out at 
> logger.trace so that you could enable that to debug stuff.
> Being able to change the RF of the system_traces KS might also help here, but 
> there would still be classes of problems that it would be good to have the 
> logging there for. Added CASSANDRA-6016 for that.



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

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



[jira] [Updated] (CASSANDRA-13745) Compaction History would be beneficial to include completion timestamp

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13745:
-
Complexity: Low Hanging Fruit

> Compaction History would be beneficial to include completion timestamp 
> ---
>
> Key: CASSANDRA-13745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13745
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core, Local/Compaction
>Reporter: Richard Andersen
>Assignee: Ihar Kukharchuk
>Priority: Low
>  Labels: lhf
> Attachments: 13745-trunk.txt
>
>
> Compaction history does not currently contain the completion time stamp which 
> can be beneficial in determining performance and event tracing. I would like 
> to use this information also in our Health Check process to trace event 
> timelines. 



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

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



[jira] [Updated] (CASSANDRA-8094) Heavy writes in RangeSlice read requests

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8094:

Complexity: Low Hanging Fruit

> Heavy writes in RangeSlice read  requests 
> --
>
> Key: CASSANDRA-8094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8094
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Coordination
>Reporter: Minh Do
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
>
> RangeSlice requests always do a scheduled read repair when coordinators try 
> to resolve replicas' responses no matter read_repair_chance is set or not.
> Because of this, in low writes and high reads clusters, there are very high 
> write requests going on between nodes.  
> We should have an option to turn this off and this can be different than the 
> read_repair_chance.



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

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



[jira] [Updated] (CASSANDRA-12166) Sequential repairs on LCS lead to many warnings

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-12166:
-
Complexity: Low Hanging Fruit

> Sequential repairs on LCS lead to many warnings
> ---
>
> Key: CASSANDRA-12166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12166
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair, Local/Compaction
>Reporter: Stefano Ortolani
>Assignee: Paulo Motta
>Priority: Low
>  Labels: lcs, lhf
>
> I have been testing sequential repairs on 3.0.8 and now the logs are filled 
> with the following warnings. Note that they do make sense since snapshotting 
> is part of the repair process if sequential, but I was wondering if this 
> level of verbosity was intended.
> {noformat}
> WARN  [ValidationExecutor:3] 2016-07-11 13:35:52,930 
> LeveledCompactionStrategy.java:231 - Live sstable 
> /data/cassandra/data/schema/cf-e06f37a010bc11e6bb236776bf484396/snapshots/acc9a360-476a-11e6-87e0-dbcbe81a0cea/mb-840-big-Data.db
>  
> from level 0 is not on corresponding level in the leveled manifest. 
> This is not a problem per se, but may indicate an orphaned sstable due to a 
> failed compaction not cleaned up properly.
> {noformat}



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

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



[jira] [Updated] (CASSANDRA-13823) The Getting Started page should have instructions on setting up a cluster

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13823:
-
Complexity: Low Hanging Fruit

> The Getting Started page should have instructions on setting up a cluster
> -
>
> Key: CASSANDRA-13823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13823
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Documentation and Website
>Reporter: Jon Haddad
>Assignee: Sumanth Pasupuleti
>Priority: Low
>  Labels: lhf
>
> Currently the docs don't have an easy to follow guide on setting up a 
> cluster.  I think it would benefit from a nice easy to follow walkthrough.
> https://cassandra.apache.org/doc/latest/getting_started/index.html



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

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



[jira] [Updated] (CASSANDRA-11419) On local cassandra installations, rack-dc from ROOT/conf isn't honored.

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-11419:
-
Complexity: Low Hanging Fruit

> On local cassandra installations, rack-dc from ROOT/conf isn't honored.
> ---
>
> Key: CASSANDRA-11419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11419
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Anubhav Kale
>Priority: Low
>  Labels: lhf
>
> 1. Get the latest sources from trunk, build in eclipse. I am doing this on 
> Windows BTW.
> 2. Run from Eclipse
> 3. Bug: The change in conf/cassandra-rackdc.properties isn't honored. 
> Instead, the one in test/conf/cassandra-rackdc.properties is honored.
> Since yaml changes from conf/ are used, why don't we stay consistent for 
> other files as well ?



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

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



[jira] [Updated] (CASSANDRA-13260) Add UDT support to Cassandra stress

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-13260:
-
Complexity: Low Hanging Fruit

> Add UDT support to Cassandra stress
> ---
>
> Key: CASSANDRA-13260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13260
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Assignee: Kevin Wern
>Priority: Normal
>  Labels: lhf, stress
>
> Splitting out UDT support in cassandra stress from CASSANDRA-9556.



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

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



[jira] [Updated] (CASSANDRA-8612) Read metrics should be updated on all types of reads

2019-06-13 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-8612:

Complexity: Low Hanging Fruit

> Read metrics should be updated on all types of reads
> 
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability/Metrics
>Reporter: Chris Lohfink
>Priority: Low
>  Labels: lhf, metrics
>
> Metrics like "sstables per read" are not updated on a range slice.  Although 
> separating things out for each type of read could make sense like we do for 
> latencies, only exposing the metrics for one type can be a little confusing 
> when people do a query and see nothing increases.  I think its sufficient to 
> use the same metrics for all reads.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Attachment: CASSANDRA-15150.txt

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Attachment: (was: CASSANDRA-15150.txt)

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Attachment: CASSANDRA-15150.txt

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Status: Patch Available  (was: Open)

Updated references to IRC in patches, bugs, contactus, and release_process for 
updating the room topic.

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Attachment: (was: CASSANDRA-15150.txt)

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update docs to point to Slack rather than IRC

2019-06-12 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Summary: Update docs to point to Slack rather than IRC  (was: Update the 
contact us/community page to point to Slack rather than IRC)

> Update docs to point to Slack rather than IRC
> -
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-10 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Status: Open  (was: Resolved)

Found a few more instances - will clean it up and submit an updated patch.

> Update the contact us/community page to point to Slack rather than IRC
> --
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Fix For: 4.0
>
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Commented] (CASSANDRA-15103) Add Failure Detection Documentation

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna commented on CASSANDRA-15103:
--

Perhaps we could put a reference to the phi accrual paper as a footnote or 
something like that - 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf
 ?

> Add Failure Detection Documentation
> ---
>
> Key: CASSANDRA-15103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15103
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Blog
>Reporter: Elijah Augustin
>Assignee: Elijah Augustin
>Priority: Normal
>  Labels: documentation, pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Topics/Concepts To Cover
>  * Why Failure Detection is needed and used
>  * State tracking with Gossip
>  * Typical Reasons for Node Failure



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

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



[jira] [Updated] (CASSANDRA-15122) cqlshrc ssl userkey and ssl usercert cannot be encrypted

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15122:
-
Component/s: Feature/Encryption

> cqlshrc ssl userkey and ssl usercert cannot be encrypted
> 
>
> Key: CASSANDRA-15122
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15122
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Encryption
>Reporter: seaside
>Priority: Normal
>
> cqlshrc ssl userkey and ssl usercert is provided when require_client_auth = 
> true,but  I did not find a way to encrypt the certificate file?



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

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



[jira] [Updated] (CASSANDRA-15127) Add compression performance metrics

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15127:
-
Component/s: Feature/Compression

> Add compression performance metrics
> ---
>
> Key: CASSANDRA-15127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15127
> Project: Cassandra
>  Issue Type: Task
>  Components: Feature/Compression, Observability/Metrics
>Reporter: Michael
>Priority: Normal
>
> When doing some bulk load into my cluster I notice almost 100% CPU usage.
> As I am using DeflateCompressor, I assume that the data 
> compression/decompression contributes a lot to overall CPU load. 
> Unfortunately cassandra doesn't seem to have any metrics explaining how much 
> CPU time has been required for that.
> So I guess it would be useful to introduce cumulative times for compression 
> and decompression, breaking down by each supported compression algorithm.
> Then by comparing how much does each specific value increase per minute, with 
> number of processed requests and their cumulative times, it would be easy to 
> conclude how costly is the compression.



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

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



[jira] [Updated] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15146:
-
Component/s: Feature/Encryption

> Transitional TLS server configuration options are overly complex
> 
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Encryption, Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> It appears as part of the port from transitional client TLS to transitional 
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using 
> {{internode_encryption}} without listening on two ports and without downtime) 
> we carried the {{enabled}} setting over from the client implementation. I 
> believe that the {{enabled}} option is redundant to {{internode_encryption}} 
> and {{optional}} and it should therefore be removed prior to the 4.0 release 
> where we will have to start respecting that interface. 
> Current trunk yaml:
> {noformat}
> server_encryption_options:
>   
> # set to true for allowing secure incoming connections
>   
> enabled: false
>   
> # If enabled and optional are both set to true, encrypted and unencrypted 
> connections are handled on the storage_port
> optional: false   
>   
>   
>   
> 
> # if enabled, will open up an encrypted listening socket on 
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false. 
>   
> enable_legacy_ssl_storage_port: false 
>   
> # on outbound connections, determine which type of peers to securely 
> connect to. 'enabled' must be set to true.
> internode_encryption: none
>   
> keystore: conf/.keystore  
>   
> keystore_password: cassandra  
>   
> truststore: conf/.truststore  
>   
> truststore_password: cassandra
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and 
> {{internode_encryption}} to determine the listener setup. I also propose we 
> change the default of {{optional}} to true. We could also re-name 
> {{optional}} since it's a new option but I think it's good to stay consistent 
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with 
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections 
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted 
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the 
> desired level of encryption (recommended {{all}}) and restart Cassandra
>  2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third 
> restart to first change {{optional}} to {{true}}, which given my 
> understanding of the OptionalSslHandler isn't really relevant.



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

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



[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Test and Documentation Plan: Perhaps just double check that the link works 
and there aren't any typos.
 Status: Patch Available  (was: Open)

> Update the contact us/community page to point to Slack rather than IRC
> --
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Attachment: CASSANDRA-15150.txt

> Update the contact us/community page to point to Slack rather than IRC
> --
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
 Complexity: Low Hanging Fruit
Change Category: Semantic
 Status: Open  (was: Triage Needed)

> Update the contact us/community page to point to Slack rather than IRC
> --
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
> Attachments: CASSANDRA-15150.txt
>
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15150:
-
Priority: Low  (was: Normal)

> Update the contact us/community page to point to Slack rather than IRC
> --
>
> Key: CASSANDRA-15150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Jeremy Hanna
>Assignee: Jeremy Hanna
>Priority: Low
>
> Update the contact us/community page to point to ASF Slack rather than IRC.  
> We can remove cassandra-builds.



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

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



[jira] [Created] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC

2019-06-04 Thread Jeremy Hanna (JIRA)
Jeremy Hanna created CASSANDRA-15150:


 Summary: Update the contact us/community page to point to Slack 
rather than IRC
 Key: CASSANDRA-15150
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15150
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation/Website
Reporter: Jeremy Hanna
Assignee: Jeremy Hanna


Update the contact us/community page to point to ASF Slack rather than IRC.  We 
can remove cassandra-builds.



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

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



[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC

2019-06-04 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna updated CASSANDRA-15071:
-
Description: 
We've recently completed a successful migration between two data centers in our 
Cassandra cluster.

After adding the new DC nodes onto the existing cluster, and setting the 
keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old 
one,  we've cut-over the applications using those keyspaces o start using the 
new DC exclusively by connecting to its end-points and performing `LOCAL_` 
consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC).

We noticed that once the apps started to read data from the materialized views 
in the new DC, that an inconsistency emerged, which wasn't there in the 
original DC from which we've migrated.
I.e - source/old DC had the materialized view reflecting the column update on 
the base table, while target/new DC didn't (the column value in the MV remained 
the same as it was in the base table, prior to the update).

We only found out about it being logged with a support ticket, and for now, 
mitigated it by simply recreating the materialized view.

Looking for a root cause for such behavior, is this expected, is this somewhat 
of a requirement which wasn't fulfilled yet for the MV mechanism, such as the 
ones mentioned in CASSANDRA-13826?

Thanks,
Avi K

  was:
We've recently completed a successful migration between two data centers in our 
Cassandra cluster.

After adding the new DC nodes onto the existing cluster, and setting the 
keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old 
one,  we've cut-over the applications using those keyspaces o start using the 
new DC exclusively by connecting to its end-points and performing `LOCAL_` 
consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC).

We noticed that once the apps started to read data from the materialized views 
in the new DC, that an inconsistency emerged, which wasn't there in the 
original DC from which we've migrated.
I.e - source/old DC had the materialized view reflecting the column update on 
the base table, while target/new DC didn't (the column value in the MV remained 
the same as it was in the base table, prior to the update).

We only found out about it being logged with a support ticket, and for now, 
mitigated it by simply recreating the materialized view.

Looking for a root cause for such behavior, is this expected, is this somewhat 
of a requirement which wasn't fulfilled yet for the MV mechanism, such as the 
ones mentioned in https://issues.apache.org/jira/browse/CASSANDRA-13826?

Thanks,
Avi K


> Materialized View Inconsistent With Base Table Update After Migrating To New 
> DC
> ---
>
> Key: CASSANDRA-15071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15071
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Bootstrap and Decommission, 
> Feature/Materialized Views
>Reporter: Avraham Kalvo
>Priority: High
>  Labels: cassandra, materializedviews, rebuilding
>
> We've recently completed a successful migration between two data centers in 
> our Cassandra cluster.
> After adding the new DC nodes onto the existing cluster, and setting the 
> keyspaces to replicate to both DCs and rebuilding the new DC nodes from the 
> old one,  we've cut-over the applications using those keyspaces o start using 
> the new DC exclusively by connecting to its end-points and performing 
> `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL 
> DC).
> We noticed that once the apps started to read data from the materialized 
> views in the new DC, that an inconsistency emerged, which wasn't there in the 
> original DC from which we've migrated.
> I.e - source/old DC had the materialized view reflecting the column update on 
> the base table, while target/new DC didn't (the column value in the MV 
> remained the same as it was in the base table, prior to the update).
> We only found out about it being logged with a support ticket, and for now, 
> mitigated it by simply recreating the materialized view.
> Looking for a root cause for such behavior, is this expected, is this 
> somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, 
> such as the ones mentioned in CASSANDRA-13826?
> Thanks,
> Avi K



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

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



  1   2   3   4   5   6   7   8   9   10   >