Re: Backports to 2.1.16

[Ben Bromhead]

this is awesome

On Thu, 20 Oct 2016 at 14:19 sankalp kohli  wrote:

> Hi,
>  We backport a lot of patches in Cassandra at Apple. We contribute all
> the patches to the community and port them to 2.1 if we think they will
> help. We will soon start focusing on 3.0 and won't back port to 2.1 unless
> critical.
>
> I want to list them in this email in random order and not based on
> importance. They are back ported for various reasons.
>
> *NOTE: This list is an FYI and I dont suggest that we port these to 2.1.*
>
> 1. Writes should be sent to a replacement node while it is streaming in
> data (CASSANDRA-8523)
> 2. Send source sstable level when bootstrapping or replacing
> nodes(CASSANDRA-7460)
> 3. Add an API to request the size of a CQL partition (CASSANDRA-12367. We
> expose this via CQL)
> 4. Add ability to blacklist a CQL partition so all requests are ignored
> (CASSANDRA-12106)
> 5. Allow compaction throttle to be real time(CASSANDRA-10025)
> 6. Add a credentials cache to the PasswordAuthenticator (CASSANDRA-7715)
> 7. SliceQueryFilter warnings should print the partition
> key(CASSANDRA-10211)
> 8. Make LZ4 Compression Level Configurable(CASSANDRA-11051)
> 9. Include info about sstable on "Compacting large row” message
> (CASSANDRA-12384)
> 10. Should be able to override compaction space check (CASSANDRA-12180)
> 11. updateJobs in PendingRangeCalculatorService should be decremented in
> finally block(CASSANDRA-12554)
> 12. Unresolved hostname in replace address (CASSANDRA-11210)
> 13. Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
> 14. range metrics are not updated for timeout and unavailable in
> StorageProxy (CASSANDRA-9507)
> 15. Range tombstones that are masked by row tombstones should not be
> written out (CASSANDRA-12030)
> 16. Disk failure policy should not be invoked on out of space
> (CASSANDRA-12385)
> 17. Add metrics for authentication failures (CASSANDRA-10635)
> 18. Implement compaction for a specific token range (CASSANDRA-10643)
> 19. RangeStreamer should be smarter when picking endpoints for
> streaming(CASSANDRA-4650)
> 20. Reject empty options and invalid DC names in replication configuration
> while creating or altering a keyspace (CASSANDRA-12681)
> 21. One way targeted repair (CASSANDRA-9876)
> 22. Rebuild from targeted replica (CASSANDRA-9875)
> 23. Add prefixes to the name of snapshots created before a truncate or
> drop(CASSANDRA-12178)
> 24. Improve CAS propose CQL query(CASSANDRA-7929)
> 25. Repair -force CASSANDRA-10446
> 26. Include table name in "Cannot get comparator"
> exception(CASSANDRA-12181)
> 27. Collect metrics on queries by consistency level (CASSANDRA-7384)
> 28. processs restarts are failing becase native port and jmx ports are in
> use(CASSANDRA-11093)
>
> Thanks,
> Sankalp
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re: Proposal - 3.5.1

[Jonathan Haddad]

>From a community perspective a supported release every 6 months would be
much more attractive than yearly, as having to wait ~9-10 months for
something like SASI is kind of frustrating.

Monthly dev releases is awesome.

On Thu, Oct 20, 2016 at 3:18 PM Nate McCall  wrote:

> > I’m not sure it makes sense to have separate features/stability releases
> in that world. 4.0.x will be stable, every 4.x will be a dev release on the
> road to 5.0.
> >
> +1. Much easier to understand and it's 'backwards compatible' (sort
> of) with wherever we leave 3.x.
>
> Still keeping 4.x on monthly cadence should keep the small, incremental
> focus.
>

Re: Proposal - 3.5.1

[Jonathan Haddad]

And +1 to ditching the "tick tock" alternating release thing nobody
understands it anyway.

On Thu, Oct 20, 2016 at 3:38 PM Jonathan Haddad  wrote:

> From a community perspective a supported release every 6 months would be
> much more attractive than yearly, as having to wait ~9-10 months for
> something like SASI is kind of frustrating.
>
> Monthly dev releases is awesome.
>
> On Thu, Oct 20, 2016 at 3:18 PM Nate McCall  wrote:
>
> > I’m not sure it makes sense to have separate features/stability releases
> in that world. 4.0.x will be stable, every 4.x will be a dev release on the
> road to 5.0.
> >
> +1. Much easier to understand and it's 'backwards compatible' (sort
> of) with wherever we leave 3.x.
>
> Still keeping 4.x on monthly cadence should keep the small, incremental
> focus.
>
>

Re: Proposal - 3.5.1

[Nate McCall]

> I’m not sure it makes sense to have separate features/stability releases in 
> that world. 4.0.x will be stable, every 4.x will be a dev release on the road 
> to 5.0.
>
+1. Much easier to understand and it's 'backwards compatible' (sort
of) with wherever we leave 3.x.

Still keeping 4.x on monthly cadence should keep the small, incremental focus.

Re: Proposal - 3.5.1

[Aleksey Yeschenko]

I’m not sure it makes sense to have separate features/stability releases in 
that world. 4.0.x will be stable, every 4.x will be a dev release on the road 
to 5.0.

-- 
AY

On 20 October 2016 at 22:43:19, Jeff Jirsa (jji...@apache.org) wrote:



On 2016-10-20 14:21 (-0700), Jeremiah Jordan  wrote:  
> In the original tick tock plan we would not have kept 4.0.x around. So I am 
> proposing a change for that and then we label the 3.x and 4.x releases as 
> "development releases" or some other thing and have "yearly" LTS releases 
> with .0.x.  
> Those are similar to the previous 1.2/2.0/2.1/2.2 and we are adding semi 
> stable development releases as well which give people an easier way to try 
> out new stuff than "build it yourself", which was the only way to do that in 
> between the previous Big Bang releases.  
>  

This sounds reasonable to me. Would 4.(even) still be features and 4.(odd) 
still be stability fixes? Or everything in 4.x is features and/or stability?  

Re: Proposal - 3.5.1

[Jeremiah D Jordan]

My thinking was we keep doing tick/tock for the 4.x.  Basically continue on for 
4.0.x / 4.x like we have been with 3.0.x / 3.x, just with some added guidance 
to people that 4.x is “development releases”.  The main problem I hear with the 
tick tock stuff is that we won’t ever have “LTS” branches any more.  So lets 
change that and make the .0 releases LTS branches.

-Jeremiah

> On Oct 20, 2016, at 4:42 PM, Jeff Jirsa  wrote:
> 
> 
> 
> On 2016-10-20 14:21 (-0700), Jeremiah Jordan  wrote: 
>> In the original tick tock plan we would not have kept 4.0.x around.  So I am 
>> proposing a change for that and then we label the 3.x and 4.x releases as 
>> "development releases" or some other thing and have "yearly" LTS releases 
>> with .0.x.
>> Those are similar to the previous 1.2/2.0/2.1/2.2 and we are adding semi 
>> stable development releases as well which give people an easier way to try 
>> out new stuff than "build it yourself", which was the only way to do that in 
>> between the previous Big Bang releases.
>> 
> 
> This sounds reasonable to me. Would 4.(even) still be features and 4.(odd) 
> still be stability fixes? Or everything in 4.x is features and/or stability? 
> 

Re: Proposal - 3.5.1

[Jeff Jirsa]

On 2016-10-20 14:21 (-0700), Jeremiah Jordan  wrote: 
> In the original tick tock plan we would not have kept 4.0.x around.  So I am 
> proposing a change for that and then we label the 3.x and 4.x releases as 
> "development releases" or some other thing and have "yearly" LTS releases 
> with .0.x.
> Those are similar to the previous 1.2/2.0/2.1/2.2 and we are adding semi 
> stable development releases as well which give people an easier way to try 
> out new stuff than "build it yourself", which was the only way to do that in 
> between the previous Big Bang releases.
> 

This sounds reasonable to me. Would 4.(even) still be features and 4.(odd) 
still be stability fixes? Or everything in 4.x is features and/or stability? 

Re: Proposal - 3.5.1

[Jeremiah Jordan]

In the original tick tock plan we would not have kept 4.0.x around.  So I am 
proposing a change for that and then we label the 3.x and 4.x releases as 
"development releases" or some other thing and have "yearly" LTS releases with 
.0.x.
Those are similar to the previous 1.2/2.0/2.1/2.2 and we are adding semi stable 
development releases as well which give people an easier way to try out new 
stuff than "build it yourself", which was the only way to do that in between 
the previous Big Bang releases.



> On Oct 20, 2016, at 3:59 PM, Jeff Jirsa  wrote:
> 
> 
> 
>> On 2016-10-20 13:26 (-0700), "J. D. Jordan"  
>> wrote: 
>> If you think of the tick tock releases as interim development releases I 
>> actually think they have been working pretty well. What if we continue with 
>> the same process and do 4.0.x as LTS like we have 3.0.x LTS.
>> 
>> So you get 4.x releases that are trickling out new features which will 
>> eventually be in the 5.0.x LTS and you get 4.0.x as an LTS release of all 
>> the 3.x built up features.
>> 
>> This seems like a fairly straight forward process to me.  It gives people 
>> monthly releases that they can test new features with, but it also provides 
>> a stable line for those that want one.
>> 
> 
> So just tick/tock with new labels? How do we stop users from getting into the 
> situation where they're running 4.5, there's a critical flaw in 4.5, and 
> there's no 4.5.1 ever going to be released? Real users still won't want to 
> jump to 4.7, because there's added risk from stuff that went into 4.6 and 4.7 
> ? Or is it simply "if you want to run bleeding edge, you better be willing to 
> stay on that bleeding edge for up to a year"? 
> 
> 
> 
> 

Backports to 2.1.16

[sankalp kohli]

Hi,
 We backport a lot of patches in Cassandra at Apple. We contribute all
the patches to the community and port them to 2.1 if we think they will
help. We will soon start focusing on 3.0 and won't back port to 2.1 unless
critical.

I want to list them in this email in random order and not based on
importance. They are back ported for various reasons.

*NOTE: This list is an FYI and I dont suggest that we port these to 2.1.*

1. Writes should be sent to a replacement node while it is streaming in
data (CASSANDRA-8523)
2. Send source sstable level when bootstrapping or replacing
nodes(CASSANDRA-7460)
3. Add an API to request the size of a CQL partition (CASSANDRA-12367. We
expose this via CQL)
4. Add ability to blacklist a CQL partition so all requests are ignored
(CASSANDRA-12106)
5. Allow compaction throttle to be real time(CASSANDRA-10025)
6. Add a credentials cache to the PasswordAuthenticator (CASSANDRA-7715)
7. SliceQueryFilter warnings should print the partition key(CASSANDRA-10211)
8. Make LZ4 Compression Level Configurable(CASSANDRA-11051)
9. Include info about sstable on "Compacting large row” message
(CASSANDRA-12384)
10. Should be able to override compaction space check (CASSANDRA-12180)
11. updateJobs in PendingRangeCalculatorService should be decremented in
finally block(CASSANDRA-12554)
12. Unresolved hostname in replace address (CASSANDRA-11210)
13. Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
14. range metrics are not updated for timeout and unavailable in
StorageProxy (CASSANDRA-9507)
15. Range tombstones that are masked by row tombstones should not be
written out (CASSANDRA-12030)
16. Disk failure policy should not be invoked on out of space
(CASSANDRA-12385)
17. Add metrics for authentication failures (CASSANDRA-10635)
18. Implement compaction for a specific token range (CASSANDRA-10643)
19. RangeStreamer should be smarter when picking endpoints for
streaming(CASSANDRA-4650)
20. Reject empty options and invalid DC names in replication configuration
while creating or altering a keyspace (CASSANDRA-12681)
21. One way targeted repair (CASSANDRA-9876)
22. Rebuild from targeted replica (CASSANDRA-9875)
23. Add prefixes to the name of snapshots created before a truncate or
drop(CASSANDRA-12178)
24. Improve CAS propose CQL query(CASSANDRA-7929)
25. Repair -force CASSANDRA-10446
26. Include table name in "Cannot get comparator" exception(CASSANDRA-12181)
27. Collect metrics on queries by consistency level (CASSANDRA-7384)
28. processs restarts are failing becase native port and jmx ports are in
use(CASSANDRA-11093)

Thanks,
Sankalp

Re: Proposal - 3.5.1

[Jeff Jirsa]

On 2016-10-20 13:26 (-0700), "J. D. Jordan"  wrote: 
> If you think of the tick tock releases as interim development releases I 
> actually think they have been working pretty well. What if we continue with 
> the same process and do 4.0.x as LTS like we have 3.0.x LTS.
> 
> So you get 4.x releases that are trickling out new features which will 
> eventually be in the 5.0.x LTS and you get 4.0.x as an LTS release of all the 
> 3.x built up features.
> 
> This seems like a fairly straight forward process to me.  It gives people 
> monthly releases that they can test new features with, but it also provides a 
> stable line for those that want one.
> 

So just tick/tock with new labels? How do we stop users from getting into the 
situation where they're running 4.5, there's a critical flaw in 4.5, and 
there's no 4.5.1 ever going to be released? Real users still won't want to jump 
to 4.7, because there's added risk from stuff that went into 4.6 and 4.7 ? Or 
is it simply "if you want to run bleeding edge, you better be willing to stay 
on that bleeding edge for up to a year"? 

Re: Re[3]: Histogram error "Unable to compute ceiling for max when histogram overflowed"

[Nate McCall]

Open a new issue and link to CASSANDRA-11063. Including a test case
addressing your issue that fails after the 11063 change would be ideal
as well.

Either way, thanks for the continued attention on this.

On Fri, Oct 21, 2016 at 4:06 AM, Владимир Бухтояров
 wrote:
> I have investigated the problem and found that monitoring was serriously 
> changed since 3.7(version when I got exception in 
> com.codahale.metrics.servlets.MetricsServlet). Since version 3.9 it is enough 
> to change behavior of DecayingEstimatedHistogramReservoir, the 
> EstimatedHistogram should stay unchanged. The modification of 
> DecayingEstimatedHistogramReservoir will be safe, because in opposite to 
> EstimatedHistogram, the DecayingEstimatedHistogramReservoir is not used for 
> Cassandra internal needs.
>
> Also I found very strange resolution of  issue  CASSANDRA-12185 - the nothing 
> done to prevent of IllegalStateException, but issue is closed. Should I 
> reopen #12185 or deliver pull request in new issue?
>
>
> Best regards,
> Bukhtoyarov Vladimir
> email jseco...@mail.ru
> skype live:fanat-tdd
> Github: https://github.com/vladimir-bukhtoyarov
> mobile +79618096798
>
>>Среда, 19 октября 2016, 21:12 +03:00 от Владимир Бухтояров 
>>:
>>
>>The null(zero) values of snapshot are useless for problem analysing, because 
>>it is impossible to distinguishing case when there are no events from case 
>>when events were dispatched too slow. I do not see any criminal to return  
>>999-th percentile as 3h when histogram configured with 3h max and any latency 
>>is 4h.
>>
>>
>>Best regards,
>>Bukhtoyarov Vladimir
>>email  jseco...@mail.ru
>>skype live:fanat-tdd
>>Github:  https://github.com/vladimir-bukhtoyarov
>>mobile  +79618096798
>>
>>>Среда, 19 октября 2016, 20:17 +03:00 от Ken Hancock < 
>>>ken.hanc...@schange.com >:
>>>
>>>I would suggest metrics should return null values instead of false values.
>>>
>>>On Wed, Oct 19, 2016 at 12:21 PM, Владимир Бухтояров <
>>> jseco...@mail.ru.invalid > wrote:
>>>

 Hi to all,

 I want to fix  https://issues.apache.org/jira/browse/CASSANDRA-11063
 This issue is very ugly for me, because when something works slow then it
 is impossible to capture metrics and save it to monitoring database for
 future investigation. Moreover when one histogram throw exception then many
 metrics-exporters are unable to export metrics for whole MetricRegistry(for
 example MetricsServlet), so when overflow happen in one histogram then I
 have no history data at all.

 I propose to implement the following changes:
 1. The DecayingEstimatedHistogramReservoir and EstimatedHistogram will
 return maximum trackable value instead of Long.MAX_VALUE
 2. The DecayingEstimatedHistogramReservoir and EstimatedHistogram will
 never throw IllegalStateException, instead, it will use maximum trackable
 value as regular value in percentile and average calculation.
 3.  If anybody want to save old behavior(prefer to crash instead of
 inaccurate reporting) then I can add configuration parameter to save
 previous behavior, moreover I can leave old behavior as default, for my
 needs it will be enough to have some option to avoid crashes.


 Best regards,
 Bukhtoyarov Vladimir
 email  jseco...@mail.ru
 skype live:fanat-tdd
 Github:  https://github.com/vladimir-bukhtoyarov

>>
>

Re: Proposal - 3.5.1

[J. D. Jordan]

If you think of the tick tock releases as interim development releases I 
actually think they have been working pretty well. What if we continue with the 
same process and do 4.0.x as LTS like we have 3.0.x LTS.

So you get 4.x releases that are trickling out new features which will 
eventually be in the 5.0.x LTS and you get 4.0.x as an LTS release of all the 
3.x built up features.

This seems like a fairly straight forward process to me.  It gives people 
monthly releases that they can test new features with, but it also provides a 
stable line for those that want one.

-Jeremiah

> On Oct 20, 2016, at 11:57 AM, Jeremy Hanna  wrote:
> 
> Thanks Ben.  It’s great to have a 3.x LTS option as things work themselves 
> out.  I just wanted to revive this thread in parallel so that it could 
> hopefully come to a way forward for the project as well.  Is the 3 branch 
> strategy that Sylvain proposed the way forward?
> 
>> On Oct 20, 2016, at 11:52 AM, Ben Bromhead  wrote:
>> 
>> For reference we have released https://github.com/instaclustr/cassandra ,
>> with the end goal that people have a stable target on the 3.x branch while
>> this is all worked out.
>> 
>> We are likely to continue our releases even with a release cadence change,
>> but we would track official versions much more closely and our repository
>> will end up just being a public view of what we do internally rather than
>> something we advocate over official releases.
>> 
>> For further details on our thoughts around this see:
>> 
>>  - https://www.instaclustr.com/blog/2016/10/19/patched-cassandra-3-7/
>>  - https://github.com/instaclustr/cassandra#faq
>> 
>> 
>> On Thu, 20 Oct 2016 at 09:38 Jeremy Hanna 
>> wrote:
>> 
>>> Is there consensus on a way forward with this?  Is there going to be a
>>> three branch plan with “features”, “testing”, and “stable” starting with
>>> 4.0?  Or is this still in the discussion mode?  External to this thread
>>> there have been decisions made to create third party LTS releases and hopes
>>> that the project would decide to address the concerns in this thread.  It
>>> seems like this is the place to complete the discussion.
>>> 
 On Sep 26, 2016, at 10:52 AM, Jonathan Haddad  wrote:
 
 Not yet. I hadn't seen any Jirsa before to release a specific version,
>>> only
 discussion on the ML.
 
 I'll put up a Jira with my patch that back ports the bug fix.
 On Mon, Sep 26, 2016 at 8:26 AM Michael Shuler 
 wrote:
 
> Jon, is there a JIRA ticket for this request? I appreciate everyone's
> input, and I think this is a fine proposal.
> 
> --
> Kind regards,
> Michael
> 
>> On 09/14/2016 08:30 PM, Jonathan Haddad wrote:
>> Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported
>>> to
>> 3.5 as well, and it makes Cassandra effectively unusable if someone is
>> using any of the 4 types affected in any of their schema.
>> 
>> I have cherry picked & merged the patch back to here and will put it
>>> in a
>> JIRA as well tonight, I just wanted to get the ball rolling asap on
>>> this.
>> 
>> 
> 
>>> https://github.com/rustyrazorblade/cassandra/tree/fix_commitlog_exception
>> 
>> Jon
>> 
> 
> 
>>> 
>>> --
>> Ben Bromhead
>> CTO | Instaclustr 
>> +1 650 284 9692
>> Managed Cassandra / Spark on AWS, Azure and Softlayer
> 

Re: Proposal - 3.5.1

[Ben Bromhead]

For reference we have released https://github.com/instaclustr/cassandra ,
with the end goal that people have a stable target on the 3.x branch while
this is all worked out.

We are likely to continue our releases even with a release cadence change,
but we would track official versions much more closely and our repository
will end up just being a public view of what we do internally rather than
something we advocate over official releases.

For further details on our thoughts around this see:

   - https://www.instaclustr.com/blog/2016/10/19/patched-cassandra-3-7/
   - https://github.com/instaclustr/cassandra#faq


On Thu, 20 Oct 2016 at 09:38 Jeremy Hanna 
wrote:

> Is there consensus on a way forward with this?  Is there going to be a
> three branch plan with “features”, “testing”, and “stable” starting with
> 4.0?  Or is this still in the discussion mode?  External to this thread
> there have been decisions made to create third party LTS releases and hopes
> that the project would decide to address the concerns in this thread.  It
> seems like this is the place to complete the discussion.
>
> > On Sep 26, 2016, at 10:52 AM, Jonathan Haddad  wrote:
> >
> > Not yet. I hadn't seen any Jirsa before to release a specific version,
> only
> > discussion on the ML.
> >
> > I'll put up a Jira with my patch that back ports the bug fix.
> > On Mon, Sep 26, 2016 at 8:26 AM Michael Shuler 
> > wrote:
> >
> >> Jon, is there a JIRA ticket for this request? I appreciate everyone's
> >> input, and I think this is a fine proposal.
> >>
> >> --
> >> Kind regards,
> >> Michael
> >>
> >> On 09/14/2016 08:30 PM, Jonathan Haddad wrote:
> >>> Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported
> to
> >>> 3.5 as well, and it makes Cassandra effectively unusable if someone is
> >>> using any of the 4 types affected in any of their schema.
> >>>
> >>> I have cherry picked & merged the patch back to here and will put it
> in a
> >>> JIRA as well tonight, I just wanted to get the ball rolling asap on
> this.
> >>>
> >>>
> >>
> https://github.com/rustyrazorblade/cassandra/tree/fix_commitlog_exception
> >>>
> >>> Jon
> >>>
> >>
> >>
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re[3]: Histogram error "Unable to compute ceiling for max when histogram overflowed"

[Владимир Бухтояров]

I have investigated the problem and found that monitoring was serriously 
changed since 3.7(version when I got exception in 
com.codahale.metrics.servlets.MetricsServlet). Since version 3.9 it is enough 
to change behavior of DecayingEstimatedHistogramReservoir, the 
EstimatedHistogram should stay unchanged. The modification of 
DecayingEstimatedHistogramReservoir will be safe, because in opposite to 
EstimatedHistogram, the DecayingEstimatedHistogramReservoir is not used for 
Cassandra internal needs.

Also I found very strange resolution of  issue  CASSANDRA-12185 - the nothing 
done to prevent of IllegalStateException, but issue is closed. Should I reopen 
#12185 or deliver pull request in new issue?


Best regards,
Bukhtoyarov Vladimir
email jseco...@mail.ru
skype live:fanat-tdd
Github: https://github.com/vladimir-bukhtoyarov
mobile +79618096798

>Среда, 19 октября 2016, 21:12 +03:00 от Владимир Бухтояров 
>:
>
>The null(zero) values of snapshot are useless for problem analysing, because 
>it is impossible to distinguishing case when there are no events from case 
>when events were dispatched too slow. I do not see any criminal to return  
>999-th percentile as 3h when histogram configured with 3h max and any latency 
>is 4h.
>
>
>Best regards,
>Bukhtoyarov Vladimir
>email  jseco...@mail.ru
>skype live:fanat-tdd
>Github:  https://github.com/vladimir-bukhtoyarov
>mobile  +79618096798
>
>>Среда, 19 октября 2016, 20:17 +03:00 от Ken Hancock < ken.hanc...@schange.com 
>>>:
>>
>>I would suggest metrics should return null values instead of false values.
>>
>>On Wed, Oct 19, 2016 at 12:21 PM, Владимир Бухтояров <
>> jseco...@mail.ru.invalid > wrote:
>>
>>>
>>> Hi to all,
>>>
>>> I want to fix  https://issues.apache.org/jira/browse/CASSANDRA-11063
>>> This issue is very ugly for me, because when something works slow then it
>>> is impossible to capture metrics and save it to monitoring database for
>>> future investigation. Moreover when one histogram throw exception then many
>>> metrics-exporters are unable to export metrics for whole MetricRegistry(for
>>> example MetricsServlet), so when overflow happen in one histogram then I
>>> have no history data at all.
>>>
>>> I propose to implement the following changes:
>>> 1. The DecayingEstimatedHistogramReservoir and EstimatedHistogram will
>>> return maximum trackable value instead of Long.MAX_VALUE
>>> 2. The DecayingEstimatedHistogramReservoir and EstimatedHistogram will
>>> never throw IllegalStateException, instead, it will use maximum trackable
>>> value as regular value in percentile and average calculation.
>>> 3.  If anybody want to save old behavior(prefer to crash instead of
>>> inaccurate reporting) then I can add configuration parameter to save
>>> previous behavior, moreover I can leave old behavior as default, for my
>>> needs it will be enough to have some option to avoid crashes.
>>>
>>>
>>> Best regards,
>>> Bukhtoyarov Vladimir
>>> email  jseco...@mail.ru
>>> skype live:fanat-tdd
>>> Github:  https://github.com/vladimir-bukhtoyarov
>>>
>

[GitHub] cassandra issue #74: fixed typo in select example

[spodkowinski]

Github user spodkowinski commented on the issue:

https://github.com/apache/cassandra/pull/74
  
Looks like this has already been fixed in 
c7f6ba8a42944338ec3e7d6793383b5537dfd82a



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Low hanging fruit crew

[Nate McCall]

Thanks Jeremy. To come back to the original idea, for an LHF crew how
about as these:
- a weekly(?) list of LHF tickets sent to dev list
- sharing fliters of the above (can we put these on the how to contribute page?)
- adopt Jeff B.'s idea of tagging LHF your own self as part of our
culture/process
- ping on a LHF Patch Ava. ticket if its been reviewed and just hanging out

Extra credit:
- ping on a PA ticket (dev list even) if its not been reviewed, but
you think it's valuable/critical and it's past your review comfort
level



On Thu, Oct 20, 2016 at 11:39 AM, Jeremy Hanna
 wrote:
> It sounds like everyone is on the same page - there won’t be a rubber stamp.  
> It’s just to have a concerted effort to help these tickets move along as 
> they’re often the first experience that contributors have with the project.  
> I’m sure many of you know of the ‘lhf' tag that’s out there with an 
> associated Jira search [1] on the How to Contribute page [2].  In the Jira 
> search, you can see several that are either “patch available” or “awaiting 
> feedback” so that search a place to start.  As for something fancier like a 
> dashboard, I currently can’t make a share-able dashboard as a contributor to 
> the project.  Perhaps committers have more permissions there.
>
> 1) 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012310865%20AND%20labels%20%3D%20lhf%20AND%20status%20!%3D%20resolved
> 2) https://wiki.apache.org/cassandra/HowToContribute
>
>
>
>> On Oct 19, 2016, at 5:27 PM, Jonathan Haddad  wrote:
>>
>> Tagging tickets as LHF is a great idea.  There's plenty of people that
>> would love to set up a JIRA dashboard saved search / nightly email for LHF
>> tickets.
>>
>> On Wed, Oct 19, 2016 at 1:34 PM Jeff Beck  wrote:
>>
>>> Would it make sense to allow people submitting the patch to flag things as
>>> LHF or small tasks? If it doesn't look like it is simple enough the team
>>> could remove the label but it may help get feedback to patches more
>>> quickly, even something saying accepted for review would be nice.
>>>
>>> Personally if a ticket sits for a few weeks I have no idea what next steps
>>> I should take to keep it moving forward. We may want to document what a
>>> person submitting a patch should do next and if it is documented we should
>>> add a link on
>>> http://cassandra.apache.org/doc/latest/development/patches.html
>>>
>>> Jeff
>>>
>>>
>>> PS: My example is https://issues.apache.org/jira/browse/CASSANDRA-12633
>>>
>>> On Wed, Oct 19, 2016 at 12:21 PM Edward Capriolo 
>>> wrote:
>>>
 Also no one has said anything to the effect of 'we want to rubber stamp
 reviews' so that ...evil reason. Many of us are coders by trade and
 understand why that is bad.

 On Wednesday, October 19, 2016, Edward Capriolo 
 wrote:

> I realize that test passing a small tests and trivial reviews will not
> catch all issues. I am  not attempting to trivialize the review
>>> process.
>
> Both deep and shallow bugs exist. The deep bugs, I am not convinced
>>> that
> even an expert looking at the contribution for N days can account for a
> majority of them.
>
> The shallow ones may appear shallow and may be deep, but given that a
>>> bug
> already exists an attempt to fix it usually does not arrive at
>>> something
> worse.
>
> Many of these issues boil down to simple, seeemingly clear fixes. Some
 are
> just basic metric addition. Many have no interaction for weeks.
>
>
> On Wednesday, October 19, 2016, Jeff Jirsa  > wrote:
>
>> Let’s not get too far in the theoretical weeds. The email thread
>>> really
>> focused on low hanging tickets – tickets that need review, but
 definitely
>> not 8099 level reviews:
>>
>> 1) There’s a lot of low hanging tickets that would benefit from
>>> outside
>> contributors as their first-patch in Cassandra (like
>> https://issues.apache.org/jira/browse/CASSANDRA-12541 ,
>> https://issues.apache.org/jira/browse/CASSANDRA-12776 )
>> 2) Some of these patches already exist and just need to be reviewed
>>> and
>> eventually committed.
>>
>> Folks like Ed and Kurt have been really active in Jira lately, and
>>> there
>> aren’t a ton of people currently reviewing/committing – that’s part of
 OSS
>> life, but the less friction that exists getting those patches reviewed
 and
>> committed, the more people will be willing to contribute in the
>>> future,
 and
>> the better off the project will be.
>>
>>
>> On 10/19/16, 9:14 AM, "Jeremy Hanna" 
 wrote:
>>
>>> And just to be clear, I think everyone would welcome more testing for
>> both regressions of new