Re: 3.0.8 AssertionError

sfesc...@gmail.com <sfesc...@gmail.com> wrote: > The first time a client connects to the cluster and sends a bunch of > inserts in parallel I get this assertion error. All subsequent inserts > (including just retrying the first requests) work fine. The only assert in > Precisi

Re: inconsistent results

; > On Tue, Feb 14, 2017 at 1:38 PM, sfesc...@gmail.com <sfesc...@gmail.com> > wrote: > > What is your query? I've seen this once when using secondary indices as it > has to reach out to all nodes for the answer. If a node doesn't respond in > time those records seem to get d

Re: inconsistent results

What is your query? I've seen this once when using secondary indices as it has to reach out to all nodes for the answer. If a node doesn't respond in time those records seem to get dropped. On Tue, Feb 14, 2017 at 1:37 PM Josh England wrote: > All client interactions are from

3.0.8 AssertionError

The first time a client connects to the cluster and sends a bunch of inserts in parallel I get this assertion error. All subsequent inserts (including just retrying the first requests) work fine. The only assert in PrecisionTime is checking if the millis argument is <= the current millis. What

Re: Maximum number of columns in a table

Another possible alternative is to use a single map column. On Thu, Sep 15, 2016 at 7:19 AM Dorian Hoxha wrote: > Since I will only have 1 table with that many columns, and the other > tables will be "normal" tables with max 30 columns, and the memory of 2K > columns

Re: Maximum number of columns in a table

needs 30 integers, or a combination of them all. >> >> On Thu, Sep 15, 2016 at 7:46 PM, DuyHai Doan <doanduy...@gmail.com> >> wrote: >> >>> "Another possible alternative is to use a single map column" >>> >>> --> how do you manage the d

Re: repair_history maintenance

onths before noticeable). I opened > https://issues.apache.org/jira/browse/CASSANDRA-12701 for discussion on > if it should use TTLs > > Chris > > On Thu, Sep 22, 2016 at 1:28 PM, sfesc...@gmail.com <sfesc...@gmail.com> > wrote: > >> Should there be a

repair_history maintenance

Should there be a maintenance schedule for repair_history? Meaning, a scheduled nodetool repair and/or deletion schedule? Or is it the intention that this table just grow for the life of the cluster?

Re: Introducing Cassandra 3.7 LTS

Wow, thank you for doing this. This sentiment regarding stability seems to be widespread. Is the team reconsidering the whole tick-tock cadence? If not, I would add my voice to those asking that it is revisited. Steve On Wed, Oct 19, 2016 at 1:00 PM Matija Gobec wrote: >

Re: scylladb

On Sat, Mar 11, 2017 at 1:52 AM Avi Kivity wrote: > > > Lastly, why don't you test Scylla yourself? It's pretty easy to set up, > there's nothing to tune. > > Avi > I'll look seriously at Scylla when it is 3.0.12 compatible.

Re: EC2 instance recommendations

I'm experimenting with bcache to see about using the ephemeral storage as a cache backed with EBS. Not sure if that makes sense in your use case though. On Tue, May 23, 2017 at 9:43 AM Jonathan Haddad wrote: > > Oh, so all the data is lost if the instance is shutdown or

Re: EC2 instance recommendations

I think this is overstating it. If the instance ever stops you'll lose the data. That means if the server crashes for example, or if Amazon decides your instance requires maintenance. On Tue, May 23, 2017 at 10:30 AM Gopal, Dhruva wrote: > Thanks! So, I assume that as