Re: Async queries

Thanks Andy for the detailed explanation. I have added the callback feature and am going to test if this helps. Charu From: Andy Tolbert Reply-To: "user@cassandra.apache.org" Date: Monday, October 2, 2017 at 5:48 PM To:

Re: Async queries

Hi Charu, Since the driver uses Guava futures, you can use some of the methods in Futures to add listeners, callbacks and transformers that are invoked when the future completes without blocking

Async queries

Hi , We are observing some performance issues when executing a large number of read/write queries. We use executeAsync query for most of our read and write requests and then future.getUninterruptibly() methods before returning to the client application. Code snippet is: (In the bind portion

Re:

Created https://issues.apache.org/jira/browse/CASSANDRA-13923 On Mon, Oct 2, 2017 at 12:06 PM, Dan Kinder wrote: > Sure will do. > > On Mon, Oct 2, 2017 at 11:48 AM, Jeff Jirsa wrote: > >> You're right, sorry I didnt read the full stack (gmail hid it

Re: Alter table gc_grace_seconds

Hi, On Mon, Oct 2, 2017 at 1:43 PM Varun Barala wrote: > Either you can change min_threshold to three in your case or you can > change compaction strategy for this table. > I've changed: alter table number_item with compaction = {'class':

Re:

Sure will do. On Mon, Oct 2, 2017 at 11:48 AM, Jeff Jirsa wrote: > You're right, sorry I didnt read the full stack (gmail hid it from me) > > Would you open a JIRA with your stack traces, and note (somewhat loudly) > that this is a regression? > > > On Mon, Oct 2, 2017 at

Re:

You're right, sorry I didnt read the full stack (gmail hid it from me) Would you open a JIRA with your stack traces, and note (somewhat loudly) that this is a regression? On Mon, Oct 2, 2017 at 11:43 AM, Dan Kinder wrote: > Right, I just meant that calling it at all

Re:

Right, I just meant that calling it at all results in holding a read lock, which unfortunately is blocking these read threads. On Mon, Oct 2, 2017 at 11:40 AM, Jeff Jirsa wrote: > > > On Mon, Oct 2, 2017 at 11:27 AM, Dan Kinder wrote: > >> (As a side

Re:

On Mon, Oct 2, 2017 at 11:27 AM, Dan Kinder wrote: > (As a side note, it seems silly to call shouldDefragment at all on a read > if the compaction strategy is not STSC) > > > It defaults to false:

Re: How do I install Cassandra on AWS

On 10/02/2017 10:53 AM, Lutaya Shafiq Holmes wrote: > > How do I install Cassandra on AWS- Amazon web services Follow the installation instructions on the following page, relevant to your OS of choice: http://cassandra.apache.org/download/ Let the list know if you have any problems! --

Re: Materialized views stability

I've been dealing with MV extensively, and I second Blake. MVs are not suitable for production. Unless you're ready for the pain (The out of sync is a major pain point), I would not go that way. Regards, Carlos Juzarte Rolo Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

How do I install Cassandra on AWS

Hi folks, How do I install Cassandra on AWS- Amazon web services -- Lutaaya Shafiq Web: www.ronzag.com | i...@ronzag.com Mobile: +256702772721 | +256783564130 Twitter: @lutayashafiq Skype: lutaya5 Blog: lutayashafiq.com http://www.fourcornersalliancegroup.com/?a=shafiqholmes "The most beautiful

Re: Materialized views stability

Hi Hannu, There are more than a few committers that don't think MVs are currently suitable for production use. I'm not involved with MV development, so this may not be 100% accurate, but the problems as I understand them are:  There's no way to determine if a view is out of sync with the base

Creating materialized view for bulk selections

I have metrics streaming in load of 10mil per minute. I am using ttl in order to maintain the retention. I have a cleanup process that needs to clean resources from other places (not cassandra) when that key is no longer exists (i.e the it's ttl reach it's due). for that I thought to maintain

Materialized views stability

Hello, I have seen some discussions around Materialized Views and stability of that functionality. There are some open issues around repairs:

Re: Alter table gc_grace_seconds

https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfigureCompaction.html As pe STCS: *This strategy triggers a minor compaction when there are a number of similar sized SSTables on disk as configured by the table subproperty, min_threshold.* In your case you have

Re: space left for compaction

Got it. Thanks On Mon, Oct 2, 2017 at 4:54 AM, Justin Cameron wrote: > Hi Avi, > > Actually, in Thomas' example you would need an additional 100G of free > disk space to complete the compaction, in the worst-case situation (the > worst-case would be that neither input

RE: Alter table gc_grace_seconds

Hello Justin, yes, but in real-world, hard to accomplish for high volume column families >= 3-digit GB. Even with the default of 10 days grace period, this may get a real challenge, to complete a full repair. ☺ Possibly back again to the discussion that incremental repair has some flaws, full

Re: Alter table gc_grace_seconds

Hi, On Mon, Oct 2, 2017 at 8:41 AM Varun Barala wrote: > Might be possible C* is not compacting the sstables [ > https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables > ] > Oh, the other CF-s in the same keyspace are compacted, but the

Re: Alter table gc_grace_seconds

Hi, On Mon, Oct 2, 2017 at 8:32 AM Justin Cameron wrote: > >> * You should not try on real clusters directly. > >Why not? :) > > It's highly recommended that you complete a full repair before the GC > grace period expires, otherwise it's possible you could experience

Re: Alter table gc_grace_seconds

+1 Justing, Might be possible C* is not compacting the sstables [ https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables ]. You can this fact by doing below procedure:- *Run this before compaction:-* ls /var/lib/cassandra/data/mat/number_item-*/ Store result to some

Re: Alter table gc_grace_seconds

>> * You should not try on real clusters directly. >Why not? :) It's highly recommended that you complete a full repair before the GC grace period expires, otherwise it's possible you could experience zombie data (i.e. data that was previously deleted coming back to life) See