Re: [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed

2014-02-27 Thread Benedict Elliott Smith
I've been investigating this, but a bit slowly as was looking in the wrong place. I haven't yet confirmed, but I have a strong suspicion of the problem. Could you confirm the total physical memory on the nodes? If 8gb or less, try applying the not yet committed patches in CASSANDRA-6692 (atomic b

Performance Tickets

2014-04-15 Thread Benedict Elliott Smith
It's only been six months since the last performance drive, and 2.1 is now around the corner. But I'm hoping we can push performance even further for 3.0. With that in mind, I've picked out what I think are the nearest term wins to focus on. - CASSANDRA-7039: DirectByteBuffer compatible LZ4

Re: Performance Tickets

2014-04-15 Thread Benedict Elliott Smith
%20project%20%3D%20CASSANDRA%20AND%20status!%3Dresolved Benedict, you might want to un-assign from yourself anything you're not working on in the near future in case anyone else wants to grab one. On Tue, Apr 15, 2014 at 3:28 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: It's only

Re: Performance Tickets

2014-04-16 Thread Benedict Elliott Smith
, Benedict Elliott Smith wrote: It's only been six months since the last performance drive, and 2.1 is now around the corner. But I'm hoping we can push performance even further for 3.0. With that in mind, I've picked out what I think are the nearest term wins to focus on. - CASSANDRA-7039

Re: CQL unit tests vs dtests

2014-05-20 Thread Benedict Elliott Smith
+1 unit tests On 21 May 2014 02:36, Jake Luciani jak...@gmail.com wrote: I think having cql unit tests is certainly a good idea. It doesn't replace dtests but makes it easier to have better coverage locally. On Tue, May 20, 2014 at 7:10 PM, Tyler Hobbs ty...@datastax.com wrote: Sylvain

Re: CMS GC / fragmentation / memtables etc

2014-05-21 Thread Benedict Elliott Smith
Graham, This is largely fixed in 2.1 with the introduction of partially off-heap memtables - the slabs reside off-heap, so do not cause any GC issues. As it happens the changes would also permit us to recycle on-heap slabs reasonable easily as well, so feel free to file a ticket for that,

Re: [jira] [Assigned] (CASSANDRA-7120) Bad paging state returned for prepared statements for last page

2014-05-21 Thread Benedict Elliott Smith
We need to add 7245 to that list. I'll try to get to it tomorrow. On 21 May 2014 17:40, Tyler Hobbs (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CASSANDRA-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Tyler Hobbs reassigned

Re: CQL unit tests vs dtests

2014-05-22 Thread Benedict Elliott Smith
I would for defining the cql tests in a way that permits them being run as both dtests and unit tests. But since we're on python for dtests that could be troublesome. On 22 May 2014 17:03, Jeremiah D Jordan jerem...@datastax.com wrote: The only thing I worry about here is that the unit tests

Re: CMS GC / fragmentation / memtables etc

2014-06-15 Thread Benedict Elliott Smith
) Thanks, Graham. On May 21, 2014, at 2:20 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: Graham, This is largely fixed in 2.1 with the introduction of partially off-heap memtables - the slabs reside off-heap, so do not cause any GC issues. As it happens the changes

Re: CMS GC / fragmentation / memtables etc

2014-06-15 Thread Benedict Elliott Smith
cassandra with different usage patterns, and it is hard to mimic production load on all of them at the same time in beta Thanks anyway for your detailed explanations, Graham On Jun 15, 2014, at 1:11 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: Hi Graham, Unfortunately

Re: CMS GC / fragmentation / memtables etc

2014-06-17 Thread Benedict Elliott Smith
to install it yourself) one. Thanks, Graham. On Jun 15, 2014, at 2:04 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: The current implementation is slower for a single memtable-only read (dependent on workload, but similar ball park to on heap), but can store substantially

Re: 2.1 rc3?

2014-07-02 Thread Benedict Elliott Smith
Pretty sure we got this head of the hydra. Question is if any more will spring up in its place. On Wed, Jul 2, 2014 at 7:28 PM, Jonathan Ellis jbel...@gmail.com wrote: https://issues.apache.org/jira/browse/CASSANDRA-7465 is a pretty big one, I'd like to get some more testing with the fix

Re: 2.1 rc3?

2014-07-07 Thread Benedict Elliott Smith
AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: Pretty sure we got this head of the hydra. Question is if any more will spring up in its place. On Wed, Jul 2, 2014 at 7:28 PM, Jonathan Ellis jbel...@gmail.com wrote: https://issues.apache.org/jira/browse/CASSANDRA

Re: Hinted Handoff/Atomic Updates SnapTree replacement with BTree

2014-07-14 Thread Benedict Elliott Smith
This discussion is probably better had on JIRA, but I favour an asynchronous approach permitting only one modifying thread access to the structure at a time, with each competing modification simply chaining their to-be-merged state to a pending-list, which is repaired at read time if it isn't

Re: [VOTE] Release Apache Cassandra 2.1.0-rc6

2014-08-13 Thread Benedict Elliott Smith
I'd prefer to patch CASSANDRA-7743 first. On Wed, Aug 13, 2014 at 10:47 PM, Brandon Williams dri...@gmail.com wrote: +1 On Aug 13, 2014 7:33 AM, Sylvain Lebresne sylv...@datastax.com wrote: I propose the following artifacts for release as 2.1.0-rc6. As it is just a RC, we'll keep the

Re: Assigning tickets

2014-09-05 Thread Benedict Elliott Smith
Done On Fri, Sep 5, 2014 at 4:34 PM, Jay Patel pateljay3...@gmail.com wrote: Hi Folks, Seems like I'm not able to assign this tix to myself. Can anyone help to assign to me? These all are actually related but I opened as separate just to track. CASSANDRA-7882

Re: [VOTE] Release Apache Cassandra 2.1.0

2014-09-07 Thread Benedict Elliott Smith
I've just commited 7519, which would be nice (but not essential) to include in 2.1.0, since it has breaking changes to the stress API Also, not sure if this is just me missing something obvious, and is probably minor to fix, but ant fails to compile on

Re: [contrib] Idea/ Reduced I/O and CPU cost for GET ops

2014-09-07 Thread Benedict Elliott Smith
Hi Mark, This specific heuristic is unlikely to be applied, as (if I've understood it correctly) it has a very narrow window of utility to only those updates that hit *exactly* the same clustering columns (cql rows) *and *data columns, and is not trivial to maintain (either cpu- or memory-wise).

Re: [VOTE] Release Apache Cassandra 2.1.0

2014-09-08 Thread Benedict Elliott Smith
Fair enough (and yes, it did) On Mon, Sep 8, 2014 at 2:40 PM, Sylvain Lebresne sylv...@datastax.com wrote: On Sep 7, 2014 4:41 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: I've just commited 7519, which would be nice (but not essential) to include in 2.1.0, since

Re: Use of System.exit() calls

2014-09-19 Thread Benedict Elliott Smith
There are some places we are unlikely to drop using System.exit(), such as when we detect a dangerous application state (e.g. OOM) However in config (e.g. DatabaseDescriptor) it's just because we haven't considered it worth our time to do anything more involved. Feel free to file a ticket and

Re: Conditional Update Code?

2015-02-06 Thread Benedict Elliott Smith
It's quite possible support could be added to evaluate a UDF as part of the condition check. The code you're looking for are implementors of CASRequest.appliesTo(), in CQL3CasRequest and CassandraServer.ThriftCASRequest It seems like https://issues.apache.org/jira/browse/CASSANDRA-8488 would

Re: [discuss] Modernization of Cassandra build system

2015-03-31 Thread Benedict Elliott Smith
I think the problem is everyone currently contributing is comfortable with ant, and as much as it is imperfect, it isn't clear maven is going to be better. Having the requisite maven functionality linked under the hood doesn't seem particularly preferable to the inverse. The status quo has the

Re: [discuss] Modernization of Cassandra build system

2015-04-02 Thread Benedict Elliott Smith
need to contribute much quicker. Here we have the same problem, we have a complex non modular build system, and core cassandra dev are used to it, so it's not needed to make something more flexible, even if it could facilite external contribution. 2015-03-31 23:42 GMT+02:00 Benedict Elliott

Re: [discuss] Modernization of Cassandra build system

2015-04-13 Thread Benedict Elliott Smith
with discipline and then measure it. IMO The only artifact worth to extract out of C* tree, and useful for a (limited) set of 3rd party code, is something like ”cassandra-jmx-interfaces.jar” Robert Am 02.04.2015 um 11:30 schrieb Benedict Elliott Smith belliottsm...@datastax.com

Re: Network transfer to one node twice as others

2015-04-22 Thread Benedict Elliott Smith
If you're connecting via thrift, all your traffic is most likely being routed to just one node, which then communicates with the other nodes for you. On Wed, Apr 22, 2015 at 6:11 AM, Anishek Agarwal anis...@gmail.com wrote: Forwarding it here, someone with Cassandra internals knowledge can help

Re: DateTieredCompactionStrategy and static columns

2015-05-01 Thread Benedict Elliott Smith
* is ahead of our SOLR indexes The static columns and the regular columns ARE completely different in behavior/lifecycle, so I’d definitely vote for them being treated as such. On May 1, 2015, at 7:27 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote

Re: DateTieredCompactionStrategy and static columns

2015-05-02 Thread Benedict Elliott Smith
) it seems much easier to flush a single memtable to more than one stable on disk (static and non static) and then allow for separate compaction of those On May 1, 2015, at 9:06 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: It also doesn't solve the atomicity problem, which

Re: DateTieredCompactionStrategy and static columns

2015-05-01 Thread Benedict Elliott Smith
How would it be different from creating an actual real extra table instead? There's nothing that warrants making the codebase more complex to accomplish something it already does. As far as I was aware, the only point of static columns was to support the thrift ability to mutate and read

Staging Branches

2015-05-07 Thread Benedict Elliott Smith
A good practice as a committer applying a patch is to build and run the unit tests before updating the main repository, but to do this for every branch is infeasible and impacts local productivity. Alternatively, uploading the result to your development tree and waiting a few hours for CI to

Re: Staging Branches

2015-05-07 Thread Benedict Elliott Smith
follow on commit wouldn't you need to force push? On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: If we do it, we'll end up in weird situations which will be annoying for everyone Such as? I'm not disputing, but if we're to assess the relative

Re: Staging Branches

2015-05-07 Thread Benedict Elliott Smith
trunk without coming across broken revisions. Then balance the value of that with the cost of the process. Ariel On Thu, May 7, 2015 at 10:41 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: It's a bit unfair to characterize Aleksey as subscribing to a cargo cult

Re: Staging Branches

2015-05-07 Thread Benedict Elliott Smith
at 10:36 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote: wouldn't you need to force push? git push --force-with-lease This works essentially like CAS; if the remote repositories are not the same as the one you have modified, it will fail. You then fetch

Re: Staging Branches

2015-05-07 Thread Benedict Elliott Smith
merge. At this size I don't see the need for a staging branch to prevent trunk from ever breaking. There is a size where it would be helpful I just don't think we are there yet. Ariel On Thu, May 7, 2015 at 5:05 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote

Re: Staging Branches

2015-05-07 Thread Benedict Elliott Smith
for trying to avoid extra work/stability but we already have added a layer of testing every change before commit. I'm not going to accept we need to also add a layer of testing before every merge. On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith belliottsm...@datastax.com wrote

Re: Requiring Java 8 for C* 3.0

2015-05-07 Thread Benedict Elliott Smith
I have no position on this, but I would like to issue a word of caution to everyone excited to use the new JDK8 features in development to please discuss their use widely beforehand, and to consider them carefully. Many of them are not generally useful to us (e.g. LongAdder), and may have

Re: [discuss] Modernization of Cassandra build system

2015-04-13 Thread Benedict Elliott Smith
02.04.2015 um 11:30 schrieb Benedict Elliott Smith belliottsm...@datastax.com: There are three distinct problems you raise: code structure, documentation, and build system. The build system, as far as I can tell, is a matter of personal preference. I personally dislike the few interactions

Re: March 2015 QA retrospective

2015-04-14 Thread Benedict Elliott Smith
. Ariel On Fri, Apr 10, 2015 at 7:07 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: CASSANDRA-8459 https://issues.apache.org/jira/browse/CASSANDRA-8459 autocompaction on reads can prevent memtable space reclaimation Can you link a ticket to CASSANDRA-9012

Re: March 2015 QA retrospective

2015-04-10 Thread Benedict Elliott Smith
on the ticket so that these scenarios are amongst those explicitly considered when we address it, but I expect the scope of that ticket to be very broad, and probably introduce its own entire class of subtickets. Thanks, Ariel On Fri, Apr 10, 2015 at 8:04 AM, Benedict Elliott Smith belliottsm

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
I've started leaning towards a hybrid approach: I put everything I want to say, including some code changes, and sometimes complex argumentation into comments the branch. I differentiate these into two categories: 1. Literal comments, to remain for posterity - typically things I agree

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
(git history navigation is also much more powerful in the IDE, in my experience - can quickly scoot through many prior versions to see what the context of prior authors was) On Wed, Jul 8, 2015 at 9:15 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: Except that it would lack code

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
Except that it would lack code navigation. So it would be alt-tabbing, then clicking through the clunky interface to find the file I want, and the location, which can be very cumbersome. On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie josh.mcken...@datastax.com wrote: If you navigate in an

Re: Discussion: reviewing larger tickets

2015-07-09 Thread Benedict Elliott Smith
While that approach optimises for people paying close attention to the JIRA firehose, it is less optimal for people trying to figure out after the fact what is going on wrt certain tickets. Some of the more complex tickets I cannot make head or tails of even when I was one of the main

Re: NewBie Question

2016-06-15 Thread Benedict Elliott Smith
For newcomers that ( https://github.com/apache/cassandra/blob/cassandra-3.0.0/guide_8099.md) is probably a bad document to point them to, as it will no doubt confuse them - the naming, behaviour and format descriptions are all now partially incorrect. It was, by its own admission, intended only

Re: COMPACT STORAGE in 4.0?

2016-04-11 Thread Benedict Elliott Smith
Compact storage should really have been named "not wasteful storage" - now everything is "not wasteful storage" so it's void of meaning. This is true without constraint. You do not need to limit yourself to a single non-PK column; you can have many and it will remain as or more efficient than

Re: COMPACT STORAGE in 4.0?

2016-04-11 Thread Benedict Elliott Smith
Jack Krupansky > > On Mon, Apr 11, 2016 at 5:03 PM, Jeremiah Jordan <jerem...@datastax.com> > wrote: > > > As I understand it "COMPACT STORAGE" only has meaning in the CQL parser > > for backwards compatibility as of 3.0. The on disk storage is not > affect

[VOTE] Release Apache Cassandra 3.8

2016-07-28 Thread Benedict Elliott Smith
I think -1 lacks a little clarity when responding to a block of prose with multiple clauses, suggestions and no single proposition requiring a yes/no answer. As fun as it is to type -1. On Thursday, 28 July 2016, Jake Luciani >

Re: A proposal to move away from Jira-centric development

2016-08-16 Thread Benedict Elliott Smith
their life and sanity. On 16 August 2016 at 20:49, Eric Evans <john.eric.ev...@gmail.com> wrote: > On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith > <bened...@apache.org> wrote: > > I think all complex, nuanced and especially emotive topics are > challenging > &

Re: A proposal to move away from Jira-centric development

2016-08-16 Thread Benedict Elliott Smith
> [not associated with Datastax] > > > > On 2016-08-16 13:47, Benedict Elliott Smith wrote: > >> This is a much more useful focusing of the discussion, in my opinion. It >> seemed to me that city hall was focusing on a very narrow definition of >> pr

Re: A proposal to move away from Jira-centric development

2016-08-16 Thread Benedict Elliott Smith
for misinterpretation, as well as correcting the inevitable misinterpretations that happen anyway. But that's a major side track we shouldn't deviate down. On 16 August 2016 at 20:28, Eric Evans <john.eric.ev...@gmail.com> wrote: > On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith

Re: A proposal to move away from Jira-centric development

2016-08-16 Thread Benedict Elliott Smith
This is a much more useful focusing of the discussion, in my opinion. It seemed to me that city hall was focusing on a very narrow definition of project health. I would be the first to say the project need to improve here, but doing so will be challenging; I'm not sure anyone really knows how

Re: A proposal to move away from Jira-centric development

2016-08-16 Thread Benedict Elliott Smith
Unfortunately when rulebooks are consulted to shape this kind of discussion, their ambiguity begins to show. What does it mean for something "to happen" on a mailing list? It must be a loose interpretation, because clearly many things do not "happen" on the mailing list, such as all of the code

Re: A proposal to move away from Jira-centric development

2016-08-15 Thread Benedict Elliott Smith
By this definition the Cassandra project is already compliant? There's a commits@ mailing list that behaves just as you describe. I'd personally like to see some reform with how these things work, but mostly because commits@ is rarely going to be subscribed to by anybody who isn't working full

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
It's worth noting more clearly that 3.5 is an arbitrary point in time. All 3.X releases < 3.6 are affected. If we backport to 3.5, it seems like 3.1 and 3.3 should get the same treatment. I do recall commitments to backport critical fixes, but exactly what the bar is was never well defined. I

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
t; > > > > I know at the summit there were a lot of ideas thrown around I can > > > regurgitate but perhaps people > > > who have been thinking about this would like to chime in and present > > ideas? > > > > > > -Jake > > > > &g

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
Yes, agreed. I'm advocating a different cadence, not a random cadence. On Thursday, 15 September 2016, Tyler Hobbs <ty...@datastax.com> wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < > bened...@apache.org <javascript:;> > > wrote: > &

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
I agree tick-tock is a failure. But for two reasons IMO: 1) Ultimately, the users are the real testers and it takes a while for a release to percolate into the wild for feedback. The reality is that a release doesn't have its tires properly kicked for at least three months after it's cut. So

Re: Moderation

2016-11-06 Thread Benedict Elliott Smith
me replying > to your messages anymore, at least on list. > > > On Nov 6, 2016, at 11:19 AM, Benedict Elliott Smith <bened...@apache.org> > wrote: > > > > In summary: you claim to be someone with years of experience at the > forefront of an organisation that cond

Re: Review of Cassandra actions

2016-11-06 Thread Benedict Elliott Smith
Jim, I would love it if you could take the time to explain how arrived at a diagnosis of trolling. Aleksey made a well written, cogent and on-topic criticism of your ongoing behaviour, as well as a reasoned rebuttal of your absurd claim that your power is inherent to *you*, not your position (I

Re: Review of Cassandra actions

2016-11-06 Thread Benedict Elliott Smith
above warrants what you consider well-written, cogent, > on-topic and reasoned, then I fear that any further discussion > is really worthless. > > o+o > > > On Nov 6, 2016, at 11:24 AM, Benedict Elliott Smith <bened...@apache.org> > wrote: > > > > Jim, >

Re: Moderation

2016-11-06 Thread Benedict Elliott Smith
In summary: you claim to be someone with years of experience at the forefront of an organisation that conducts all of its business primarily over email. In that time you have not learned to express yourself over email in a manner that is not incendiary to those reading it, nor offensive to the

Re: DataStax role in Cassandra and the ASF

2016-11-05 Thread Benedict Elliott Smith
Thanks Jeff, that was very well put. I would quibble on one point, though: the ship has never sailed on topics of community. How the board acts towards the PMC and companies in the community matters a great deal for continuing relations, as well as for other projects. The question is: did the

Re: DataStax role in Cassandra and the ASF

2016-11-05 Thread Benedict Elliott Smith
id a lot for Cassandra, but the public perception nowadays > seems to be that DataStax donated Cassandra to the ASF. This is not true. > It was created and contributed by Facebook > https://wiki.apache.org/incubator/Cassandramany years before DataStax was > even founded > > &g

Re: DataStax role in Cassandra and the ASF

2016-11-05 Thread Benedict Elliott Smith
LONG time. Just not in public. So this is nothing which just > boiled up the last month - this really got pointed out amicably by the > board for a LONG time before _finally_ they took actions! > > > LieGrue, > strub > > > On Saturday, 5 November 2016, 14:42, Benedict Ellio

DataStax role in Cassandra and the ASF

2016-11-05 Thread Benedict Elliott Smith
ow what’s been happening inside your > project, we don’t pass judgement. To make us care you must have your > community speak with one voice. Demonstrate that you have consensus around > your opinions. Then, and only then, will the membership - the people who > vote for the board and ho

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

2016-11-05 Thread Benedict Elliott Smith
Hi Ed, I would like to try and clear up what I perceive to be some misunderstandings. Aleksey is relating that for *complex* tickets there are desperately few people with the expertise necessary to review them. In some cases it can amount to several weeks' work, possibly requiring multiple

Re: DataStax role in Cassandra and the ASF

2016-11-04 Thread Benedict Elliott Smith
This discussion is bundling up two issues: 1) Did DataStax have an outsized role on the project which needed to be offset, preferably with increased participation? 2) Did the Board behave reasonably in trying to fix it? As far as I can tell the answers are 1) Yes, 2) No Can the board please

Re: DataStax role in Cassandra and the ASF

2016-11-04 Thread Benedict Elliott Smith
PMC > should understand how the project should be run, its not the boards job to > fix it directly. Did the board act unreasonably? I don't think so. Did some > heated discussions take place? Undoubtedly. > > > > On Sat, Nov 5, 2016 at 12:28 AM, Benedict Elliott Smith < > b

Re: Review of Cassandra actions

2016-11-07 Thread Benedict Elliott Smith
Hi Mark, Thanks, that was a calm and diplomatic email. recognise where they might need to apologise I will start the ball rolling here, as I have not always been generous in my interpretations of others' actions, and have certainly contributed to escalation. But I wonder if you would also

Re: Use of posix_fadvise

2016-10-18 Thread Benedict Elliott Smith
... and continuing in the fashion of behaviours one might like to disabuse people of, no code link is provided. On 18 October 2016 at 16:28, Michael Kjellman wrote: > We use posix_fadvise in a bunch of places, and in stereotypical Cassandra > fashion no comments

Re: Use of posix_fadvise

2016-10-18 Thread Benedict Elliott Smith
This is what JIRA is for. It seems to date back to CASSANDRA-1470, where the default became immediately evicting newly compacted files. This results in cold reads for *hot* data after compaction, so CASSANDRA-6916 permitted evicting the *old* data instead, while guaranteeing >= the same amount

Re: Use of posix_fadvise

2016-10-18 Thread Benedict Elliott Smith
commits and read thru a billion tickets to maybe understand why > something was done. Clearly thru the conversations on this topic I've had > on IRC and the responses so far on this email thread it's not/still not > obvious. > > best, > kjellman > > On Oct 18, 20

Re: Moderation

2016-11-04 Thread Benedict Elliott Smith
Wow, that was quite the aggressive email. The thing is, it very much looks like the only reason you care about this delay is because Kellabyte is making the ASF board look bad on twitter. If it weren't the case, it seems unlikely such a "slow" 12hr response would receive board notice, let alone

Re: Moderation

2016-11-04 Thread Benedict Elliott Smith
Mattmann <mattm...@apache.org> wrote: > > > On 2016-11-04 09:51 (-0700), Benedict Elliott Smith <bened...@apache.org> > wrote: > > Wow, that was quite the aggressive email. The thing is, it very much > looks > > like the only reason you care about this delay is

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Benedict Elliott Smith
This link is a helpful segway to another problem with MVs and defaults - the default behavioural unsafety we opt for by not writing through the batch log, opening far more windows for data inconsistency than the algorithm otherwise permits. Without a way to detect or repair these

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Benedict Elliott Smith
the specifics of > any other features. So yes, I would prefer my bank to use MV’s as they are > today over rolling their own, and getting it even more wrong. > > Now, even given all that, if we want to warn users of the pit falls of using > MV’s, then lets do that. But l

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Benedict Elliott Smith
While many users may apparently be using MVs successfully, the problem is how few (if any) know what guarantees they are getting. Since we aren’t even absolutely certain ourselves, it cannot be many. Most of the shortcomings we are aware of are complicated, concern failure scenarios and

Re: duration based config settings

2017-12-04 Thread Benedict Elliott Smith
I'm strongly in favour of it; it's always bugged me, and I hadn't realised it might be contentious to implement. I'd be in favour of never retiring the _ms format though - it's almost free, there's no backward compatibility problems, and it's fairly intuitive so long as we're consistent about it.

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
We already store the minimum timestamp in the EncodingStats of each partition, to support more efficient encoding of atom timestamps. This just isn't exposed beyond UnfilteredRowIterator, though it probably could be. Storing the max alongside would still require justification, though its cost

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
(Obviously, not to detract from the points that Jon and Jeremiah make, i.e. that if TTLs or tombstones are involved the metadata we have, or can add, is going to be worthless in most cases anyway) On 14 January 2018 at 16:11, Benedict Elliott Smith <bened...@apache.org> wrote: > We alre

Re: Getting partition min/max timestamp

2018-01-14 Thread Benedict Elliott Smith
t for me? > > On 2018-01-14 17:16, Benedict Elliott Smith <bened...@apache.org> wrote: > > (Obviously, not to detract from the points that Jon and Jeremiah make, > i.e. > > that if TTLs or tombstones are involved the metadata we have, or can add, > > is going to be w

Re: Coordinator Write Metrics per CF

2018-02-13 Thread Benedict Elliott Smith
For the record, I'm not certain there *is* a great deal of value in this. The read latency metrics are expected to vary a great deal, since the entire IO subsystem is involved. Writes, however, go straight to a memtable. They only block on IO if we exceed our commit log flush bandwidth for an

Re: Use of OpOrder in memtable

2018-02-13 Thread Benedict Elliott Smith
If you look closely, there can be multiple memtables extant at once. While all "new" writes are routed to the latest memtable, there may still be writes that have begun but not yet completed. The memtable cannot be flushed until any stragglers have completed, and some stragglers *may* still need

Re: Coordinator Write Metrics per CF

2018-02-13 Thread Benedict Elliott Smith
Sorry, I guess I'm tired. I thought this was discussing local write latency. I'm surprised we have that and not coordinator write latency. Please do ignore me, I'm not sure why I got involved! On 13 February 2018 at 21:48, Benedict Elliott Smith <bened...@apache.org> wrote: > For t

Re: Use of OpOrder in memtable

2018-02-13 Thread Benedict Elliott Smith
; including SSTable read and timestamp comparison etc.) > > -Original Message- > From: Benedict Elliott Smith [mailto:bened...@apache.org] > Sent: Tuesday, February 13, 2018 2:25 PM > To: dev@cassandra.apache.org > Subject: Re: Use of OpOrder in memtable > > If y

Re: GitHub PR ticket spam

2018-07-30 Thread Benedict Elliott Smith
I agree this is a mess. I think we have previously taken the view that JIRA should be the permanent record of discussion, and that as such the git conversation should be duplicated there. However, I think it would be better for JIRA to get a summary of important discussions, by one of the

Re: GitHub PR ticket spam

2018-08-06 Thread Benedict Elliott Smith
Also +1 It might perhaps be nice to (just once) have ASF Bot comment that a GitHub discussion has been replicated to the worklog? In the Arrow example, for instance, it isn’t immediately obvious that there are any worklog comments to look at. Or perhaps we should require committers to

Re: Side Car New Repo vs not

2018-08-23 Thread Benedict Elliott Smith
+1 also for separate repo > On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: > > +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,

Re: Testing 4.0 Post-Freeze

2018-07-09 Thread Benedict Elliott Smith
+1. > On 9 Jul 2018, at 20:17, Mick Semb Wever wrote: > > >> We have done all this for previous releases and we know it has not worked >> well. So how giving it one more try is going to help here. Can someone >> outline what will change for 4.0 which will make it more successful? > > > I

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Benedict Elliott Smith
That’s a peculiar way of looking at it. Committer status is not an absolute right to autonomy over the codebase. It’s an embodiment of trust that you will follow the community's prevailing rules around commit, and that you’re competent to do so. If the community wants to change those rules

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Benedict Elliott Smith
it's > probably just noise now, so I won't respond any further on this > thread. I don't anticipate having a personal need to commit to a > future 5.0 release before 4.0 is out, so it won't impact me > personally. > > On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith > w

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
ound(1) returns double 3 >> >> So as we're going to have silly values in any case, why pretend something >> else? Also, exact calculations are slow if we crunch large amount of >> numbers. I guess I slightly deviated towards Postgres' implemention in this >> case, but

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
double. This would be something the spec allows. > > Definitely if we can make overflow not occur we should and the spec allows > that. We should also not return different types for the same operand types > just to work around overflow if we detect we need more precision. &

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
a lot. It's a bit >>> suspicious really when you look at the ratio of performance to block size >>> being close to 1:1. I couldn't spot a bug in the benchmark though. >>> >>> Compression ratios with LZ4 fast for the text of Alice in Wonderland was: >>> >&

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
Shall we move this discussion to a separate thread? I agree it needs to be had, but this will definitely derail this discussion. To respond only to the relevant portion for this thread: > changing years-old defaults I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-18 Thread Benedict Elliott Smith
FWIW, I’m not -0, just think that long after the freeze date a change like this needs a strong mandate from the community. I think the change is a good one. > On 17 Oct 2018, at 22:09, Ariel Weisberg wrote: > > Hi, > > It's really not appreciably slower compared to the decompression we

Re: Implicit Casts for Arithmetic Operators

2018-10-12 Thread Benedict Elliott Smith
As far as I can tell we reached a relatively strong consensus that we should implement lossless casts by default? Does anyone have anything more to add? Looking at the emails, everyone who participated and expressed a preference was in favour of the “Postgres approach” of upcasting to decimal

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-24 Thread Benedict Elliott Smith
is old, I've learned that it pays to > be very, very cautious. > > On Tue, Oct 23, 2018 at 3:33 PM Jeff Jirsa wrote: > >> My objection (-0.5) is based on freeze not in code complexity >> >> >> >> -- >> Jeff Jirsa >> >> >>> O

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-23 Thread Benedict Elliott Smith
I’m +1 change of default. I think Jeff was -1 on that though. > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon Haddadd > Ben Bromhead > Alain Rodriguez > Sankalp Kohli (not explicit)

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-23 Thread Benedict Elliott Smith
.5 respectively. > > Ariel > > On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: >> I’m +1 change of default. I think Jeff was -1 on that though. >> >> >>> On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: >>> >>> Hi, >

Re: Proposed changes to CircleCI testing workflow

2018-10-26 Thread Benedict Elliott Smith
Just want to say +1, and thanks for taking the time to do this. This all sounds great. (And completely supersedes what I hoped to achieve with CASSANDRA-14648) > On 26 Oct 2018, at 15:49, Stefan Podkowinski wrote: > > I'd like to give you a quick update on the work that has been done >

  1   2   >