Thanks for the feedback.
It seems we agree to the config property, disabled by default in trunk.
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?
On Tue, 15 Jan 2019 at 11:24,
additionally, a certain number of the threads in each stage could be
restricted from serving the low-priority queues at all, say 8/32 or 16/32
threads, to further ensure processing availability to the higher-priority
tasks.
On Wed, Jan 16, 2019 at 3:04 PM Carl Mueller
wrote:
> At a theoretical
Also it costs us nothing to add it.
On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad wrote:
> I'm +1 on the warning for two reasons.
>
> > A cqlsh warning only applies to those that create the sasi via cqlsh.
>
> 1. When people are creating their schemas in development, this is usually
> the
The cost is in how many users you scare away
--
Jeff Jirsa
> On Jan 16, 2019, at 2:34 PM, Brandon Williams wrote:
>
> Also it costs us nothing to add it.
>
>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad wrote:
>>
>> I'm +1 on the warning for two reasons.
>>
>>> A cqlsh warning only
On 1/16/19 1:05 PM, Jonathan Haddad wrote:
> Ping on this.
https://issues.apache.org/jira/browse/CASSANDRA-14970
I could just punt and use what we've got with md5,sha1 checksums, then
toss sha256,sha512 checksums in dist repo, when we're done. It's not
pretty, but would work for me. That method
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?
I'm -0 on this.
A single line warning in the logs on the sasi creation won't be noticed by many
users.
A cqlsh warning only
I'm +1 on the warning for two reasons.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
1. When people are creating their schemas in development, this is usually
the first step. You use the REPL to figure out what you need, then you
copy your schema somewhere else. The
Ping on this.
On Mon, Jan 7, 2019 at 5:58 PM Michael Shuler
wrote:
> No problem, thanks for asking :)
>
> Michael
>
> On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> > It's been 5 months and 30+ bug fixes to each branch.
> >
> > Here's the two changelogs:
> >
> >
At a theoretical level assuming it could be implemented with a magic wand,
would there be value to having a dual set of queues/threadpools at each of
the SEDA stages inside cassandra for a two-tier of priority? Such that you
could mark queries that return pages and pages of data as lower-priority
I’m all for it. Apart from general testing with an existing app, do we have
automation to bring up / run stress / tear down the cluster?
I have a few endurance tests I can run written on Gatling.
Rahul Singh
Chief Executive Officer
m 202.905.2818
Anant Corporation
1010 Wisconsin Ave NW, Suite
I understand the goal.
Thinking in this direction , multiple queues make sense if there is enough
processing power / multiple cores and memory. There is some over head involved
to determine priority and send to the proper queue / routing.
I would say that having the ability to addition queues
Which, if I'm not mistaken, is the goal here?
On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa wrote:
> The cost is in how many users you scare away
>
> --
> Jeff Jirsa
>
>
> > On Jan 16, 2019, at 2:34 PM, Brandon Williams wrote:
> >
> > Also it costs us nothing to add it.
> >
> >> On Wed, Jan 16,
A second vote for any bugfixes we can get for 2.1, we'd probably use it.
We are finally getting traction behind upgrades with an automated
upgrade/rollback for 2.1 --> 2.2, but it's going to be a while.
Aaron, if you want to use our 2.1-2.2 migration tool, we can talk about at
the next MPLS
13 matches
Mail list logo
