Re: question on the code formatter

2017-09-14 Thread Murukesh Mohanan
The wiki seems to be outdated. See https://github.com/apache/cassandra/blob/trunk/doc/source/development/ide.rst : > The project generated by the ant task ``generate-idea-files`` contains nearly everything > you need to debug Cassandra and execute unit tests. > > * Run/debug defaults for JUnit >

question on the code formatter

2017-09-14 Thread Tyagi, Preetika
Hi all, I was trying to configure the Cassandra code formatter and downloaded IntelliJ-codestyle.jar from this link: https://wiki.apache.org/cassandra/CodeStyle After extracting this JAR, I was able to import codestyle/Default_1_.xml into my project and formatting seemed to work. However, I'm

Re: Proposal: Closing old, unable-to-repro JIRAs

2017-09-14 Thread Jason Brown
Jeff, fantastic idea. +1 John, i'd prefer to get the non-PA ones out of the way first. With PA, someone at least tried to improve to software. I'm not at a computer now, but it would be instructive to have a beak down of those types of tickets by age. I can do that later. Jason On Thu, Sep 14, 2

Re: Proposal: Closing old, unable-to-repro JIRAs

2017-09-14 Thread Jonathan Haddad
I think it's a great idea. I'd like to do the same thing with the available patches but I'm totally ok with doing that separately. On Thu, Sep 14, 2017 at 4:50 PM Jeff Jirsa wrote: > There's a number of JIRAs that are old - sometimes very old - that > represent bugs that either don't exist in mod

Re: Proposal: Closing old, unable-to-repro JIRAs

2017-09-14 Thread Eduard Tudenhoefner
+1, if it turns out that something is still valid/important, then people can always re-open. On Thu, Sep 14, 2017 at 4:50 PM, Jeff Jirsa wrote: > There's a number of JIRAs that are old - sometimes very old - that > represent bugs that either don't exist in modern versions, or don't have > suffic

Proposal: Closing old, unable-to-repro JIRAs

2017-09-14 Thread Jeff Jirsa
There's a number of JIRAs that are old - sometimes very old - that represent bugs that either don't exist in modern versions, or don't have sufficient information for us to repro, but the reporter has gone away. Would anyone be offended if I start tagging these with the label 'UnableToRepro' or 'U

Re: repair hangs, validation failed

2017-09-14 Thread Micha
ok, thanks, so I don't use the -pr option anymore (I used it on the first node). It seems to take some time. running for 150minutes to complete 7% ... Cheers, Michael On 14.09.2017 15:40, Alexander Dejanovski wrote: > There should be no migration needed, but if you have a lot of data, > antic

Re: repair hangs, validation failed

2017-09-14 Thread Alexander Dejanovski
There should be no migration needed, but if you have a lot of data, anticompaction could take a while the first time. The only way to make that fast would be to mark all sstables as repaired, and then start running incremental repair every day or so to have small datasets to anticompact. But all th

Re: repair hangs, validation failed

2017-09-14 Thread Micha
ok, I have restarted the cluster to stop all repairs. There is no "migration" process to move to incremental repair in 3.11? So I can start "nodetool repair -pr" node after node or just "nodetool repair" on one node? Cheers, Michael On 14.09.2017 10:47, Alexander Dejanovski wrote: > Hi Micha

Re: repair hangs, validation failed

2017-09-14 Thread Alexander Dejanovski
Hi Micha, Are you running incremental repair ? If so, then validation fails when 2 repair sessions are running at the same time, with one anticompacting an SSTable and the other trying to run a validation compaction on it. If you check the logs of the nodes that is referred to in the "Validation

repair hangs, validation failed

2017-09-14 Thread Micha
Hi, I started a repair (7 nodes, C* 3.11) but at once I get an exception in the log: "RepairException: [# on keyspace/table, [], Validation failed in /ip" The started nodetool repair hangs (the whole day...), strace shows it's waiting... What's the reason for this excpetion and what to