[VOTE RESULT] Release Apache Cassandra 3.0.9

[Jake Luciani]

With 11 binding +1, 5 non-binding +1 and no -1 the vote passes. I will
publish.

On Mon, Sep 19, 2016 at 2:19 AM, Tommy Stendahl  wrote:

> +1 (non binding)
>
>
>
> On 2016-09-15 20:57, Jake Luciani wrote:
>
>> I propose the following artifacts for release as 3.0.9.
>>
>> sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012
>> Git:
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
>> rtlog;h=refs/tags/3.0.9-tentative
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapache
>> cassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapache
>> cassandra-1124/
>>
>> The artifacts as well as the debian package are also available here:
>> http://people.apache.org/~jake
>>
>> The vote will be open for 72 hours (longer if needed).
>>
>> [1]: https://goo.gl/JKkE05 (CHANGES.txt)
>> [2]: https://goo.gl/Hi8X71 (NEWS.txt)
>>
>>
>


-- 
http://twitter.com/tjake

Re: Proposal - 3.5.1

[Eric Evans]

On Thu, Sep 15, 2016 at 9:33 PM, Mick Semb Wever  wrote:
>  - keep bimonthly feature releases,
>  - revert from tick-tock to SemVer numbering scheme,
>  - during the release vote also vote on the quality label (feature branches
> start with a 'Alpha' and the first patch release as 'Beta'),
>  - accept that every feature release isn't by default initially supported,
> and its branch might never be,
>  - maintain 3 'GA' branches at any one time,
>  - accept that it's not going to be the oldest GA branches that necessarily
> reach EOL first.

I like it.

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Proposal - 3.5.1

[Eric Evans]

On Fri, Sep 16, 2016 at 5:05 AM, Sylvain Lebresne  wrote:
> In light of all this, my suggesting for a release cycle woud be:
> - To have 3 branches: 'features', 'testing' and 'stable', with an X month
>   rotation: 'features' becomes 'testing' after X months and then 'stable'
> after
>   X more, before getting EOL X months later.
> - The feature branch gets everything. The testing branch only gets bug
> fixes.
>   The stable branch only gets critical bug fixes. And imo, we should be very
>   strict on this (I acknowledge that there is sometimes a bit of
> subjectivity on
>   whether something is a bug or an improvement, and if it's critical or
> not, but
>   I think it's not that hard to get consensus if we're all reasonable
> (though it
>   might worth agreeing on some rough but written guideline upfront)).
> - We release on a short and fixed cadence of Y month(s) for both the
> feature and
>   testing branch. For the stable branch, given that it already had X months
> of
>   only bug fixes during the testing phase, one can hope critical fixes will
> be
>   fairly rare, less than 1 per Y period on average). Further, it's supposed
> to
>   be stable and fixes are supposed to be critical, so doing hot-fix releases
>   probably makes the most sense (though it probably only work if we're
> indeed
>   strict on what is considered critical).

This seems pretty close to what Mck suggested; I think this could work.


-- 
Eric Evans
john.eric.ev...@gmail.com

Guidelines for test coverage

[sankalp kohli]

Hi,
I wanted to know if there are any guidelines for contributors to give
out unit and integration tests along with the patches. If not, we should
discuss and have them in place.

I know we are making good progress with test coverage but we should add
guidelines around adding unit and integration tests with every patch.
Thoughts on this?

Thanks,
Sankalp

Hints handoff is memory intensive

[Dikang Gu]

In our 2.1 cluster, I find that hints handoff is using a lot of memory on
our proxy nodes, when delivering hints to a data node that was dead for 3+
hours (our hints window is 3 hours). It makes the young gen GC time as long
as 2 secs.

I'm using 64G max heap size, and 4G young gen size. I'm considering
increasing the young gen size, I'm wondering any improvements to hints
handoff in newer version?

some logs:
2016-09-20_05:04:30.67928 INFO  05:04:30 [Service Thread]: ParNew GC in
2200ms.  CMS Old Gen: 49112623080 -> 50052787792; Par Eden Space:
2863398912 -> 0;

mem usage:
2016-09-20T01:25:23.522+ Process summary
  process cpu=0.00%
  application cpu=140.36% (user=132.28% sys=8.08%)
  other: cpu=-140.36%
  heap allocation rate 1500mb/s
[001343] user=90.42% sys= 0.01% alloc= 1439mb/s - HintedHandoff:3
[290234] user=18.85% sys= 5.14% alloc=   40mb/s - CompactionExecutor:176226
[064445] user=17.57% sys= 1.09% alloc=   10mb/s - RMI TCP
Connection(148376)-127.0.0.1
[290439] user= 3.20% sys= 1.10% alloc= 4607kb/s - RMI TCP
Connection(148380)-127.0.0.1
[16] user= 0.75% sys=-0.03% alloc= 2321kb/s - ScheduledTasks:1
[000149] user= 0.32% sys=-0.04% alloc= 1516kb/s - GossipStage:1
[001370] user= 0.11% sys= 0.04% alloc=  420kb/s - GossipTasks:1

Thanks
Dikang.

Re: Hints handoff is memory intensive

[Eduard Tudenhoefner]

The way how hints work under the hood was improved in C* 3.0.

Please take a look at
http://www.datastax.com/dev/blog/whats-coming-to-cassandra-in-3-0-improved-hint-storage-and-delivery
for further details

On Tue, Sep 20, 2016 at 8:12 AM, Dikang Gu  wrote:

> In our 2.1 cluster, I find that hints handoff is using a lot of memory on
> our proxy nodes, when delivering hints to a data node that was dead for 3+
> hours (our hints window is 3 hours). It makes the young gen GC time as long
> as 2 secs.
>
> I'm using 64G max heap size, and 4G young gen size. I'm considering
> increasing the young gen size, I'm wondering any improvements to hints
> handoff in newer version?
>
> some logs:
> 2016-09-20_05:04:30.67928 INFO  05:04:30 [Service Thread]: ParNew GC in
> 2200ms.  CMS Old Gen: 49112623080 -> 50052787792; Par Eden Space:
> 2863398912 -> 0;
>
> mem usage:
> 2016-09-20T01:25:23.522+ Process summary
>   process cpu=0.00%
>   application cpu=140.36% (user=132.28% sys=8.08%)
>   other: cpu=-140.36%
>   heap allocation rate 1500mb/s
> [001343] user=90.42% sys= 0.01% alloc= 1439mb/s - HintedHandoff:3
> [290234] user=18.85% sys= 5.14% alloc=   40mb/s - CompactionExecutor:176226
> [064445] user=17.57% sys= 1.09% alloc=   10mb/s - RMI TCP
> Connection(148376)-127.0.0.1
> [290439] user= 3.20% sys= 1.10% alloc= 4607kb/s - RMI TCP
> Connection(148380)-127.0.0.1
> [16] user= 0.75% sys=-0.03% alloc= 2321kb/s - ScheduledTasks:1
> [000149] user= 0.32% sys=-0.04% alloc= 1516kb/s - GossipStage:1
> [001370] user= 0.11% sys= 0.04% alloc=  420kb/s - GossipTasks:1
>
> Thanks
> Dikang.
>



-- 

[image: DataStaxLogo copy3.png] 

Eduard Tudenhoefner

Software Engineer | +49 151 206 111 97 | eduard.tudenhoef...@datastax.com