Re: Jira Suggestion

2019-05-14 Thread Jeff Jirsa
Please -- Jeff Jirsa > On May 14, 2019, at 7:53 AM, Benedict Elliott Smith > wrote: > > How would people feel about introducing a field for the (git) commit SHA, to > be required on (Jira) commit? > > The norm is that we comment the SHA, but given this is the norm

Re: How Apache Cassandra handles flaky tests

2019-02-26 Thread Jeff Jirsa
> On Feb 26, 2019, at 8:26 AM, Stanislav Kozlovski > wrote: > > Hey there Cassandra community, > > I work on a fellow open-source project - Apache Kafka - and there we have > been fighting flaky tests a lot. We run Java 8 and Java 11 builds on every > Pull Request and due to test

Re: CASSANDRA-14482

2019-02-15 Thread Jeff Jirsa
+1 -- Jeff Jirsa > On Feb 15, 2019, at 9:35 AM, Jonathan Ellis wrote: > > IMO "add a new compression class that has demonstrable benefits to Sushma > and Joseph" is sufficiently noninvasive that we should allow it into 4.0. > > On Fri, Feb 15, 2019 at 10

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-05 Thread Jeff Jirsa
+1 On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler wrote: > I propose the following artifacts for release as 3.0.18. > > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative > Artifacts: > >

Re: [VOTE] Release Apache Cassandra 2.2.14

2019-02-05 Thread Jeff Jirsa
+1 On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler wrote: > I propose the following artifacts for release as 2.2.14. > > sha1: af91658353ba601fc8cd08627e8d36bac62e936a > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative > Artifacts: > >

Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-05 Thread Jeff Jirsa
+1 (to the release, I see no reason to force this to be EOL; leaving the branch open has zero cost, and if a serious enough patch comes up, we'll likely be happy we have the option to fix it). On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler wrote: > *EOL* release for the 2.1 series. There will

Re: [VOTE] Release Apache Cassandra 3.11.4

2019-02-05 Thread Jeff Jirsa
+1 On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler wrote: > I propose the following artifacts for release as 3.11.4. > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative > Artifacts: > >

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-02 Thread Jeff Jirsa
There’s SO MUCH that needs to go out, let’s just get out what we have -- Jeff Jirsa > On Feb 2, 2019, at 5:35 PM, Benedict Elliott Smith > wrote: > > CASSANDRA-14812 should probably land in this release, given that it is a > critical bug, has been patch availa

Re: SSTable exclusion from read path based on sstable metadata marked by custom compaction strategies

2019-02-01 Thread Jeff Jirsa
Iterate over all of the possible time buckets. On Fri, Feb 1, 2019 at 1:36 PM Carl Mueller wrote: > I'd still need a "all events for app_id" query. We have seconds-level > events :-( > > > On Fri, Feb 1, 2019 at 3:02 PM Jeff Jirsa wrote: > > > On Fri, Fe

Re: SSTable exclusion from read path based on sstable metadata marked by custom compaction strategies

2019-02-01 Thread Jeff Jirsa
number of sstables accessed when a LIMIT > > clause was used. This can be a pretty big win with TWCS. > > > > > > > http://thelastpickle.com/blog/2017/03/07/The-limit-clause-in-cassandra-might-not-work-as-you-think.html > > > > On Thu, Jan 31, 2019 at 5:50 PM Jeff

Re: SSTable exclusion from read path based on sstable metadata marked by custom compaction strategies

2019-02-01 Thread Jeff Jirsa
:11 PM Jonathan Haddad > wrote: > > > >> In addition to what Jeff mentioned, there was an optimization in 3.4 > that > >> can significantly reduce the number of sstables accessed when a LIMIT > >> clause was used. This can be a pretty big win with TWCS. >

Re: SSTable exclusion from read path based on sstable metadata marked by custom compaction strategies

2019-01-31 Thread Jeff Jirsa
there was some issue with this and RTs recently, so I’m not sure if it’s current state, but worth considering that this may be much better on 3.0+ -- Jeff Jirsa > On Jan 31, 2019, at 1:56 PM, Carl Mueller > wrote: > > Situation: > > We use TWCS for a task history table

Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Jeff Jirsa
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

Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jeff Jirsa
+1 on config -0 on warning -0 on disabling by default -- Jeff Jirsa > On Jan 14, 2019, at 9:22 PM, Taylor Cressy wrote: > > +1 on config. +1 on disabling. > > +1 on applying it to materialized views as well. > >> On Jan 14, 2019, at 17:29, Joshua McKenzie wr

Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jeff Jirsa
When we say disable, do you mean disable creation of new SASI indices, or disable using existing ones? I assume it's just creation of new? On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña wrote: > Hello all, > > It is my understanding that SASI is still to be considered an > experimental/beta

Re: Who should be in our distribution KEYS file?

2019-01-07 Thread Jeff Jirsa
I dont think it's awkward, I think a lot of us know there are serious bugs and we need a release, but we keep finding other bugs and it's super tempting to say "one more fix" We should probably just cut next 3.0.x and 3.11.x though, because there are some nasty bugs hiding in there that the

Re: Git Repo Migration

2019-01-04 Thread Jeff Jirsa
+1 -- Jeff Jirsa > On Jan 4, 2019, at 2:49 AM, Sam Tunnicliffe wrote: > > As per the announcement on 7th December 2018[1], ASF infra are planning to > shutdown the service behind git-wip-us.apache.org and migrate all existing > repos to gitbox.apache.org > > Ther

Re: Question about PartitionUpdate.singleRowUpdate()

2018-12-19 Thread Jeff Jirsa
Definitely worth a JIRA. Suspect it may be slow to get a response this close to the holidays, but a JIRA will be a bit more durable than the mailing list post. On Wed, Dec 19, 2018 at 1:58 PM Sam Klock wrote: > Cassandra devs, > > I have a question about the implementation of >

Re: [VOTE] Change Jira Workflow

2018-12-17 Thread Jeff Jirsa
+1 -- Jeff Jirsa > On Dec 17, 2018, at 7:19 AM, Benedict Elliott Smith > wrote: > > I propose these changes > <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>* > to the Jira Workflow for the project. The vote will be open f

Re: Inter-node messaging latency

2018-11-28 Thread Jeff Jirsa
Are you sure you’re blocked on internode and not commitlog? Batch is typically not what people expect (group commitlog in 4.0 is probably closer to what you think batch does). -- Jeff Jirsa > On Nov 27, 2018, at 10:55 PM, Yuji Ito wrote: > > Hi, > > Thank you for th

Re: Request for reviewer: CASSANDRA-14829

2018-11-16 Thread Jeff Jirsa
The assignment is just so you get “credit” for the patch - asking for a reviewer is good but not strictly necessary. (Some of the committers will try to review it when we can, usually waiting for someone who’s comfortable with that code to come along) -- Jeff Jirsa > On Nov 16, 2018, at

Re: Deprecating/removing PropertyFileSnitch?

2018-10-29 Thread Jeff Jirsa
gt; wrote: > >>>>>>>>> > >>>>>>>>>>> the new host won’t learn about the host whose status is > missing and > >>>>>>>> the > >>>>>>>>>> view of this host will b

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-23 Thread Jeff Jirsa
My objection (-0.5) is based on freeze not in code complexity -- Jeff Jirsa > On Oct 23, 2018, at 8:59 AM, Benedict Elliott Smith > wrote: > > To discuss the concerns about the patch for a more efficient representation: > > The risk from such a patch is very low.

Re: Deprecating/removing PropertyFileSnitch?

2018-10-22 Thread Jeff Jirsa
On Mon, Oct 22, 2018 at 7:09 PM J. D. Jordan wrote: > Do you have a specific gossip bug that you have seen recently which caused > a problem that would make this happen? Do you have a specific JIRA in mind? Sankalp linked a few others, but also

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jeff Jirsa
Agree with Sylvain (and I think Benedict) - there’s no compelling reason to violate the freeze here. We’ve had the wrong default for years - add a note to the docs that we’ll be changing it in the future, but let’s not violate the freeze now. -- Jeff Jirsa > On Oct 19, 2018, at 10:06

Re: Built in trigger: double-write for app migration

2018-10-18 Thread Jeff Jirsa
are often app specific -- Jeff Jirsa > On Oct 18, 2018, at 6:47 PM, Jonathan Ellis wrote: > > Isn't this what CDC was designed for? > > https://issues.apache.org/jira/browse/CASSANDRA-8844 > > On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller > wrote: > >> t

Re: Built in trigger: double-write for app migration

2018-10-18 Thread Jeff Jirsa
The write sampling is adding an extra instance with the same schema to test things like yaml params or compaction without impacting reads or correctness - it’s different than what you describe -- Jeff Jirsa > On Oct 18, 2018, at 5:57 PM, Carl Mueller > wrote: > > I guess t

Re: Using Cassandra as local db without cluster

2018-10-18 Thread Jeff Jirsa
I can’t think of a situation where I’d choose Cassandra as a database in a single-host use case (if you’re sure it’ll never be more than one machine). -- Jeff Jirsa > On Oct 18, 2018, at 12:31 PM, Abdelkrim Fitouri wrote: > > Hello, > > I am wondering if using cassand

Re: Deprecating/removing PropertyFileSnitch?

2018-10-16 Thread Jeff Jirsa
We should, but the 4.0 features that log/reject verbs to invalid replicas solves a lot of the concerns here -- Jeff Jirsa > On Oct 16, 2018, at 4:10 PM, Jeremy Hanna wrote: > > We have had PropertyFileSnitch for a long time even though > GossipingPropertyFileSnitch is

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-12 Thread Jeff Jirsa
> On Oct 12, 2018, at 6:46 AM, Pavel Yaskevich wrote: > >> On Thu, Oct 11, 2018 at 4:31 PM Ben Bromhead wrote: >> >> This is something that's bugged me for ages, tbh the performance gain for >> most use cases far outweighs the increase in memory usage and I would even >> be in favor of

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-11 Thread Jeff Jirsa
I think 16k is a better default, but it should only affect new tables. Whoever changes it, please make sure you think about the upgrade path. > On Oct 12, 2018, at 2:31 AM, Ben Bromhead wrote: > > This is something that's bugged me for ages, tbh the performance gain for > most use cases

Re: MD5 in the read path

2018-09-26 Thread Jeff Jirsa
In some installations, it's used for hashing the partition key to find the host ( RandomPartitioner ) It's used for prepared statement IDs It's used for hashing the data for reads to know if the data matches on all different replicas. We don't use CRC because conflicts would be really bad.

Re: [DISCUSS] changing default token behavior for 4.0

2018-09-21 Thread Jeff Jirsa
Also agree it should be lowered, but definitely not to 1, and probably something closer to 32 than 4. -- Jeff Jirsa > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna wrote: > > I agree that it should be lowered. What I’ve seen debated a bit in the past > is the number but I don’t

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jeff Jirsa
On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne wrote: > That's probably a stupid question, and excuse me if it is, but what does > those votes on the dev mailing list even mean? > > How do you count votes at the end? Just by counting all votes cast, > irregardless of whomever cast it? Or are

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jeff Jirsa
d - good with either option, but would probably slightly prefer b, as it can be build towards the design doc. On Wed, Sep 12, 2018 at 8:19 AM sankalp kohli wrote: > Hi, > Community has been discussing about Apache Cassandra Management process > since April and we had lot of discussion

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jeff Jirsa
+1 (Incubation looks like it may be challenging to get acceptance from all existing contributors, though) -- Jeff Jirsa > On Sep 12, 2018, at 8:12 AM, Nate McCall wrote: > > This will be the same process used for dtest. We will need to walk > this through the incubator per

Re: UDF

2018-09-11 Thread Jeff Jirsa
+1 as well. On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko wrote: > If this is about inclusion in 4.0, then I support it. > > Technically this is *mostly* just a move+donation of some code from > java-driver to Cassandra. Given how important this seemingly is to the > board and PMC for us

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Jeff Jirsa
of what was proposed. -- Jeff Jirsa > On Sep 7, 2018, at 6:53 PM, Blake Eggleston wrote: > > What’s the benefit of doing it that way vs starting with reaper and > integrating the netflix scheduler? If reaper was just a really inappropriate > choice for the cassandra management proce

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Jeff Jirsa
, starting with something small and isolated and layering on top. -- Jeff Jirsa > On Sep 7, 2018, at 5:42 PM, Blake Eggleston wrote: > > I think we should accept the reaper project as is and make that cassandra > management process 1.0, then integrate the netflix scheduler (a

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Jeff Jirsa
How can we continue moving this forward? Mick/Jon/TLP folks, is there a path here where we commit the Netflix-provided management process, and you augment Reaper to work with it? Is there a way we can make a larger umbrella that's modular that can support either/both? Does anyone believe there's

Re: Request for post-freeze merge exception

2018-09-04 Thread Jeff Jirsa
Seems like a reasonable thing to merge to me. Nothing else has been committed, it was approved pre-freeze, seems like the rush to merge was bound to have some number of rebase casualties. On Tue, Sep 4, 2018 at 11:15 AM Sam Tunnicliffe wrote: > Hey all, > > On 2018-31-08 CASSANDRA-14145 had

Re: Java 11 Z garbage collector

2018-08-31 Thread Jeff Jirsa
Read heavy workload with wider partitions (like 1-2gb) and disable the key cache will be worst case for GC -- Jeff Jirsa > On Aug 31, 2018, at 10:51 AM, Carl Mueller > wrote: > > I'm assuming that p99 that Rocksandra tries to target is caused by GC > pauses, does a

Re: Reaper as cassandra-admin

2018-08-29 Thread Jeff Jirsa
Agreed here - combining effort and making things pluggable seems like a good solution -- Jeff Jirsa On Aug 28, 2018, at 11:44 PM, Vinay Chella wrote: >> I haven’t settled on a position yet (will have more time think about > things after the 9/1 freeze), but I wanted to

Re: Supporting multiple JDKs

2018-08-28 Thread Jeff Jirsa
+1 from me on both points below -- Jeff Jirsa > On Aug 28, 2018, at 1:40 PM, Sumanth Pasupuleti > wrote: > > Correct me if I am wrong, but I see the following consensus so far, on the > proposal. > > C* 2.2 > AnimalSniffer > Use AnimalSniffer for compi

Re: Reaper as cassandra-admin

2018-08-27 Thread Jeff Jirsa
with the ability to meet the goals of the original proposal (and then some). The reaper UI is nice, I wish you’d have talked to the other group of folks to combine efforts in April, we’d be much further ahead. -- Jeff Jirsa > On Aug 27, 2018, at 6:02 PM, Jeff Jirsa wrote: > > Can yo

Re: Reaper as cassandra-admin

2018-08-27 Thread Jeff Jirsa
Can you get all of the contributors cleared? What’s the architecture? Is it centralized? Is there a sidecar? > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad wrote: > > Hey folks, > > Mick brought this up in the sidecar thread, but I wanted to have a clear / > separate discussion about what

Re: Side Car New Repo vs not

2018-08-23 Thread Jeff Jirsa
+1 for separate repo -- Jeff Jirsa > On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote: > > Separate repo is in a majority so far. Please reply to this thread with > your responses. > > On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh > wrote: > >> +1 for se

Re: Proposing an Apache Cassandra Management process

2018-08-20 Thread Jeff Jirsa
On Mon, Aug 20, 2018 at 4:14 PM Roopa Tangirala wrote: > contributions should be evaluated based on the merit of code and their > value add to the whole offering. I hope it does not matter whether that > contribution comes from PMC member or a person who is not a committer. I hope this goes

Re: NGCC 2018?

2018-07-26 Thread Jeff Jirsa
Bay area event is interesting to me, in any format. On Thu, Jul 26, 2018 at 9:03 PM, Ben Bromhead wrote: > It sounds like there may be an appetite for something, but the NGCC in its > current format is likely to not be that useful? > > Is a bay area event focused on C* developers something

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

2018-07-25 Thread Jeff Jirsa
+1 On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.11.3. > > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.11.3-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 2.2.13

2018-07-25 Thread Jeff Jirsa
+1 On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler wrote: > I propose the following artifacts for release as 2.2.13. > > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/2.2.13-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

2018-07-25 Thread Jeff Jirsa
+1 On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.0.17. > > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.0.17-tentative > Artifacts: >

Re: Scratch an itch

2018-07-12 Thread Jeff Jirsa
On Thu, Jul 12, 2018 at 10:54 AM, Michael Burman wrote: > On 07/12/2018 07:38 PM, Stefan Podkowinski wrote: > >> this point? Also, if we tell someone that their contribution will be >> reviewed and committed later after 4.0-beta, how is that actually making >> a difference for that person,

Re: [VOTE] Branching Change for 4.0 Freeze

2018-07-11 Thread Jeff Jirsa
+1 -- Jeff Jirsa > On Jul 11, 2018, at 2:46 PM, sankalp kohli wrote: > > Hi, >As discussed in the thread[1], we are proposing that we will not branch > on 1st September but will only allow following merges into trunk. > > a. Bug and Perf fixes to 4.0. > b. Crit

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Jeff Jirsa
Ultimately, we have a consensus driven development. If Jonathan or Dave strongly disagrees with this, they can share their strong disagreement. Jonathan shared his concern about dissuading contributors. What's absurd is trying the same thing we've tried for 10 years and expecting things to

Re: Testing 4.0 Post-Freeze

2018-07-03 Thread Jeff Jirsa
Yes? -- Jeff Jirsa > On Jul 3, 2018, at 2:29 PM, Jonathan Ellis wrote: > > Is that worth the risk of demotivating new contributors who might have > other priorities? > >> On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa wrote: >> >> I think there's valu

Re: Testing 4.0 Post-Freeze

2018-07-03 Thread Jeff Jirsa
I think there's value in the psychological commitment that if someone has time to contribute, their contributions should be focused on validating a release, not pushing future features. On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad wrote: > I agree with Josh. I don’t see how changing the

Re: [VOTE] Release Apache Cassandra 3.0.17

2018-07-02 Thread Jeff Jirsa
+1 On Mon, Jul 2, 2018 at 1:10 PM, Michael Shuler wrote: > I propose the following artifacts for release as 3.0.17. > > sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2 > Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho > rtlog;h=refs/tags/3.0.17-tentative > Artifacts:

Re: [VOTE] Release Apache Cassandra 3.11.3

2018-07-02 Thread Jeff Jirsa
+1 On Mon, Jul 2, 2018 at 1:11 PM, Michael Shuler wrote: > I propose the following artifacts for release as 3.11.3. > > sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd > Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho > rtlog;h=refs/tags/3.11.3-tentative > Artifacts:

Re: [VOTE] Release Apache Cassandra 2.2.13

2018-07-02 Thread Jeff Jirsa
+1 On Mon, Jul 2, 2018 at 1:10 PM, Michael Shuler wrote: > I propose the following artifacts for release as 2.2.13. > > sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645 > Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho > rtlog;h=refs/tags/2.2.13-tentative > Artifacts:

Re: Tombstone passed GC period causes un-repairable inconsistent data

2018-06-21 Thread Jeff Jirsa
Think he's talking about https://issues.apache.org/jira/browse/CASSANDRA-6434 Doesn't solve every problem if you don't run repair at all, but if you're not running repairs, you're nearly guaranteed problems with resurrection after gcgs anyway. On Thu, Jun 21, 2018 at 11:33 AM, Jay Zhuang

Re: secondary index table - tombstones surviving compactions

2018-05-18 Thread Jeff Jirsa
This would matter for the base table, but would be less likely for the secondary index, where the partition key is the value of the base row Roman: there’s a config option related to only purging repaired tombstones - do you have that enabled ? If so, are you running repairs? -- Jeff Jirsa

Re: Academic paper about Cassandra database compaction

2018-05-14 Thread Jeff Jirsa
Interesting! I suspect I know what the increased disk usage in TWCS, and it's a solvable problem, the problem is roughly something like this: - Window 1 has sstables 1, 2, 3, 4, 5, 6 - We start compacting 1, 2, 3, 4 (using STCS-in-TWCS first window) - The TWCS window rolls over - We flush

Spring 2018 Cassandra Dev Wrap-up

2018-05-12 Thread Jeff Jirsa
Here's what's going on in the Cassandra world this spring: Mailing list: - Kurt sent out a call for reviewers: https://lists.apache.org/thread.html/f1f7926d685b7f734edb180aeddc3014d79dc6e5f89e68b751b9eb5e@%3Cdev.cassandra.apache.org%3E - Dinesh proposed a management sidecar:

Re: Evolving the client protocol

2018-04-28 Thread Jeff Jirsa
On Sat, Apr 28, 2018 at 4:49 AM, mck wrote: > We should, as open source contributors, put business concerns to the side > and welcome opportunities to work across company and product lines. > I resent the fact that you're calling this a business concern. This isn't a business

Re: Evolving the client protocol

2018-04-24 Thread Jeff Jirsa
They aren't even remotely similar, they're VERY different. Here's a few starting points: 1) Most of Datastax's work for the first 5, 6, 8 years of existence focused on driving users to cassandra from other DBs (see all of the "Cassandra Summits" that eventually created trademark friction) ;

Re: Evolving the client protocol

2018-04-23 Thread Jeff Jirsa
. The spec is what the server implements. Anything we don’t implement can use the arbitrary payload from the zipkin tracing ticket or fork. -- Jeff Jirsa > On Apr 23, 2018, at 6:18 PM, Nate McCall <zznat...@gmail.com> wrote: > > Folks, > Before this goes much further, let'

Re: Evolving the client protocol

2018-04-22 Thread Jeff Jirsa
On Apr 20, 2018, at 5:03 AM, Sylvain Lebresne wrote: >> >> >> Those were just given as examples. Each would be discussed on its own, >> assuming we are able to find a way to cooperate. >> >> >> These are relatively simple and it wouldn't be hard for use to patch >>

Re: Evolving the client protocol

2018-04-18 Thread Jeff Jirsa
Removed other lists (please don't cross post) On Wed, Apr 18, 2018 at 3:47 AM, Avi Kivity wrote: > Hello Cassandra developers, > > > We're starting to see client protocol limitations impact performance, and > so we'd like to evolve the protocol to remove the limitations.

Re: Quantifying Virtual Node Impact on Cassandra Availability

2018-04-17 Thread Jeff Jirsa
to LCS in particular - I’m fairly confident there’s a JIRA for this, if not it’s been discussed in person among various operators for years as an obvious future improvement. -- Jeff Jirsa > On Apr 17, 2018, at 8:17 AM, Carl Mueller <carl.muel...@smartthings.com> > wrote: &g

Re: Roadmap for 4.0

2018-04-12 Thread Jeff Jirsa
rough some canned > >> > scenarios we have internally. We aren't in a position to test data > >> validity > >> > (yet) but we can do a lot around cluster behavior. > >> > > >> > Who else has specific stuff they are willing to do? Even if it's ju

Re: Roadmap for 4.0

2018-04-11 Thread Jeff Jirsa
One clarifying point, potentially trivia, but: On Wed, Apr 11, 2018 at 9:42 AM, Ben Bromhead wrote: > > We haven't seen any actual binding -1s yet on June 1, despite obvious > concerns and plenty of +1s > > Just to be clear: binding -1 votes are vetos for code changes, but

Re: Roadmap for 4.0

2018-04-10 Thread Jeff Jirsa
-- Jeff Jirsa On Apr 10, 2018, at 5:24 PM, Josh McKenzie <jmcken...@apache.org> 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

Re: Roadmap for 4.0

2018-04-10 Thread Jeff Jirsa
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: Roadmap for 4.0

2018-04-09 Thread Jeff Jirsa
I'd like to see pluggable storage and transient replica tickets land, for starters. On Mon, Apr 9, 2018 at 10:17 AM, Ben Bromhead wrote: > > > > For those wanting to delay, are we just dancing around inclusion of > > some pet features? This is fine, I just think we need to

Re: Roadmap for 4.0

2018-04-04 Thread Jeff Jirsa
Earlier than I’d have personally picked, but I’m +1 too -- Jeff Jirsa > On Apr 4, 2018, at 5:06 PM, Nate McCall <zznat...@gmail.com> wrote: > > Top-posting as I think this summary is on point - thanks, Scott! (And > great to have you back, btw). > > It feels to m

Re: Roadmap for 4.0

2018-04-03 Thread Jeff Jirsa
A hard date for a feature freeze makes sense, a hard date for a release does not. -- Jeff Jirsa > On Apr 3, 2018, at 2:29 PM, Michael Shuler <mich...@pbandjelly.org> wrote: > > On 04/03/2018 03:51 PM, Nate McCall wrote: >>> My concrete proposal would be to declare

Re: Roadmap for 4.0

2018-04-02 Thread Jeff Jirsa
9608 (java9) -- Jeff Jirsa > On Apr 2, 2018, at 3:45 AM, Jason Brown <jasedbr...@gmail.com> wrote: > > The only additional tickets I'd like to mention are: > > https://issues.apache.org/jira/browse/CASSANDRA-13971 - Automatic > certificate management using

Re: Paying off tech debt and correctly naming things

2018-03-21 Thread Jeff Jirsa
Please please please ping the list and ask if anyone has big commits ready to merge before actually committing any huge automated refactors - people who may be sitting on big patches will thank you if they don’t have to rebase against huge IntelliJ refactors . -- Jeff Jirsa > On Mar

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

2018-03-21 Thread Jeff Jirsa
> On Mar 21, 2018, at 7:21 AM, Gerald Henriksen wrote: > >> On Wed, 21 Mar 2018 14:04:39 +0100, you wrote: >> Bundling a custom JRE along with Cassandra, would be convenient in a way >> that we can do all the testing against the bundled Java version. We >> could also

Re: Debug logging enabled by default since 2.2

2018-03-18 Thread Jeff Jirsa
debug and start backing out some of the changes in 10241. Putting stuff like compaction in the same bucket as digest mismatch and gossip state doesn’t make life materially better for most people. -- Jeff Jirsa > On Mar 18, 2018, at 11:21 AM, Jonathan Ellis <jbel...@gmail.com&

Re: Making RF4 useful aka primary and secondary ranges

2018-03-14 Thread Jeff Jirsa
Write at CL 3 and read at CL 2 -- Jeff Jirsa > On Mar 14, 2018, at 2:40 PM, Carl Mueller <carl.muel...@smartthings.com> > wrote: > > Currently there is little use for RF4. You're getting the requirements of > QUORUM-3 but only one extra backup. > > I'd like to p

Cassandra Wrapup: Feb 2018 Edition

2018-03-04 Thread Jeff Jirsa
there are any "official" groups, but search your favorite sites, you'll likely find one near you). I'm Jeff Jirsa, and this was the February 2018 Cassandra Dev Wrapup.

Re: penn state academic paper - "scalable" bloom filters

2018-02-22 Thread Jeff Jirsa
per sstable -- Jeff Jirsa > On Feb 22, 2018, at 5:47 PM, Jay Zhuang <z...@uber.com> wrote: > > I think there's a similar idea here to dynamically resize the BF: > https://issues.apache.org/jira/browse/CASSANDRA-6633, but I don't quite > understand the idea there. > &

Re: Why isn't there a separate JVM per table?

2018-02-22 Thread Jeff Jirsa
Bloom filters are offheap. To be honest, there may come a time when it makes sense to move compaction into its own JVM, but it would be FAR less effort to just profile what exists now and fix the problems. On Thu, Feb 22, 2018 at 2:52 PM, Carl Mueller wrote: >

Re: Cassandra Needs to Grow Up by Version Five!

2018-02-21 Thread Jeff Jirsa
On Wed, Feb 21, 2018 at 2:53 PM, Kenneth Brotman < kenbrot...@yahoo.com.invalid> wrote: > Hi Akash, > > I get the part about outside work which is why in replying to Jeff Jirsa I > was suggesting the big companies could justify taking it on easy enough and > you know actual

Re: Cassandra Needs to Grow Up by Version Five!

2018-02-19 Thread Jeff Jirsa
talk some folks into helping out. - Jeff On Mon, Feb 19, 2018 at 1:01 AM, Kenneth Brotman < kenbrot...@yahoo.com.invalid> wrote: > Comments inline > > >-Original Message----- > >From: Jeff Jirsa [mailto:jji...@gmail.com] > >Sent: Sunday, Febru

Re: Cassandra Needs to Grow Up by Version Five!

2018-02-18 Thread Jeff Jirsa
Comments inline > On Feb 18, 2018, at 9:39 PM, Kenneth Brotman > wrote: > > Cassandra feels like an unfinished program to me. The problem is not that > it’s open source or cutting edge. It’s an open source cutting edge program > that lacks some of its basic

Re: scheduled work compaction strategy

2018-02-16 Thread Jeff Jirsa
There’s a company using TWCS in this config - I’m not going to out them, but I think they do it (or used to) with aggressive tombstone sub properties. They may have since extended/enhanced it somewhat. -- Jeff Jirsa > On Feb 16, 2018, at 2:24 PM, Carl Mueller <carl.muel...@smartthin

Release votes

2018-02-15 Thread Jeff Jirsa
said in the past that we don’t release without green tests. The PMC gets to vote and enforce it. If you don’t vote yes without seeing the test results, that enforces it. -- Jeff Jirsa > On Feb 15, 2018, at 9:49 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > What would

Re: row tombstones as a separate sstable citizen

2018-02-15 Thread Jeff Jirsa
> https://issues.apache.org/jira/browse/CASSANDRA-7019 ? I think it may > >> go a ways to reducing the need for something complicated like this. > >> Though it is an interesting idea as special handling for bulk deletes. > >> If they were truly just sstables that only

Re: row tombstones as a separate sstable citizen

2018-02-13 Thread Jeff Jirsa
On Tue, Feb 13, 2018 at 2:38 PM, Carl Mueller wrote: > In process of doing my second major data purge from a cassandra system. > > Almost all of my purging is done via row tombstones. While performing this > the second time while trying to cajole compaction to occur

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

2018-02-13 Thread Jeff Jirsa
Using the internals in ThreadAwareSecurityManager has caused countless problems, and needs to be fixed once and for all - There are 2 different patches up for review in https://issues.apache.org/jira/browse/CASSANDRA-13396 - would be nice if one could be selected, and hopefully whichever is

Re: Roadmap for 4.0

2018-02-12 Thread Jeff Jirsa
Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible part of that. 2) Having a huge changelog in a release increases the likelihood of bugs that take time to find. Advantages of a slower release: 1) We don't do major

Re: [VOTE] Release Apache Cassandra 2.1.20

2018-02-12 Thread Jeff Jirsa
+1 On Mon, Feb 12, 2018 at 1:03 PM, Brandon Williams wrote: > +1 > > On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.1.20. > > > > sha1: b2949439ec62077128103540e42570238520f4ee > >

Re: [VOTE] Release Apache Cassandra 2.2.12

2018-02-12 Thread Jeff Jirsa
+1 On Mon, Feb 12, 2018 at 1:02 PM, Brandon Williams wrote: > +1 > > On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.2.12. > > > > sha1: 1602e606348959aead18531cb8027afb15f276e7 > >

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

2018-02-12 Thread Jeff Jirsa
+1 On Mon, Feb 12, 2018 at 7:40 PM, Michael Shuler wrote: > I propose the following artifacts for release as 3.11.2. > > sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >

Re: [VOTE] Release Apache Cassandra 3.0.16

2018-02-12 Thread Jeff Jirsa
+1 On Mon, Feb 12, 2018 at 1:03 PM, Brandon Williams wrote: > +1 > > On Mon, Feb 12, 2018 at 2:31 PM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.0.16. > > > > sha1: 91e83c72de109521074b14a8eeae1309c3b1f215 > > Git:

Re: Search in cassandra

2018-02-09 Thread Jeff Jirsa
Are you referencing a specific book or section of docs? Can you link that here so there’s context? -- Jeff Jirsa > On Feb 8, 2018, at 8:21 AM, Mahdi Manavi <mahdi.manav...@gmail.com> wrote: > > As in the "search in lost data" section , we should get tombstone fr

Cassandra Monthly Dev Roundup: Jan 2018 Edition

2018-01-31 Thread Jeff Jirsa
Happy 2018 Cassandra Developers, I hope you all had a good holiday season. In going through some of the tickets/emails, I'm pretty happy - we had some contributions from some big and interesting companies I didn't even realize were using Cassandra, and that's always fun to see [1]. If you

  1   2   3   >