Failed request after changing compression strategy from LZ4 to Deflate and using upgradesstable

Hi, My Compression strategy in Production was *LZ4 Compression. *But I modified it to *Deflate *using alter command For compression change, we have to use *nodetool Upgradesstables *to forcefully upgrade the compression strategy on all sstables But once upgradesstabloes command completed on all

Re: Roadmap for 4.0

On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad wrote: [ ... ] > If they're not close to finished now why even consider them for > the 4.0 release? They're so core they should be merged into trunk at the > beginning of the cycle for the follow up release in order to get as

Re: Roadmap for 4.0

Hi, I am +1 on freezing features at some point. Here are my thoughts 1. The reason it took 1.5 years b/w 3.0 and 4.0 is because 3.0 was released(not cut) too early. There were so many critical bugs in it for months after the release. Most people have just finished or about to upgrade to 3.0.

Re: Roadmap for 4.0

A lot of good points and everyone's input is really appreciated. So it sounds like we are building consensus towards June 1 for 4.0 branch point/feature freeze and the goal is stability. (No one has come with a hard NO anyway). I want to reiterate Sylvain's point that we can do whatever we want

Re: Roadmap for 4.0

Seriously, what's the rush to branch? Do we all love merging so much we want to do a few more times just for the sake of merging? If nothing diverges, there's nothing gained from the branch, and if it did diverge, we add work for no real gain. Beyond that, I still don't like June 1. Validating

Re: Failed request after changing compression strategy from LZ4 to Deflate and using upgradesstable

Hi Hitesh, This list is for conversations regarding Cassandra development. Can you subscribe and post this to us...@cassandra.apache.org instead? You will get a much wider audience when you do. On Tue, Apr 10, 2018 at 10:45 PM, hitesh dua wrote: > Hi, > My Compression

Re: Roadmap for 4.0

> I'd like to see pluggable storage and transient replica tickets land, for > starters. So after all the fuss and scandal about incremental repair and MV not stable and being downgraded to experimental, I would like to suggest that those new features are also flagged as experimental for some time

Re: Repair scheduling tools

My two cents as a (relatively small) user. I'm coming at this from the ops/user side, so my apologies if some of these don't make sense based on a more detailed understanding of the codebase: Repair is definitely a major missing piece of Cassandra. Integrated would be easier, but a sidecar

Re: Roadmap for 4.0

I think moving it to August/Sept will be better On Apr 10, 2018, at 17:24, Josh McKenzie wrote: >> >> 50'ish days is too short to draw a line in the sand, >> especially as people balance work obligations with Cassandra feature >> development. > > What's a reasonable

Re: Roadmap for 4.0

Also in this time we should try to see who can do 3 things I mentioned in my earlier email > On Apr 10, 2018, at 17:50, Sankalp Kohli wrote: > > I think moving it to August/Sept will be better > > On Apr 10, 2018, at 17:24, Josh McKenzie wrote:

Re: Roadmap for 4.0

-- Jeff Jirsa On Apr 10, 2018, at 5:24 PM, Josh McKenzie wrote: >> >> 50'ish days is too short to draw a line in the sand, >> especially as people balance work obligations with Cassandra feature >> development. > > What's a reasonable alternative / compromise for