Hi Jay,
Here's the backport to 3.0.14 -
https://github.com/whangsf/cassandra/commit/8db2e3ed412e42fed1da2d85ee7d086edcc8ae4c.
This should pass all unit tests, but please let me know if you have any
issues.
Thanks,
Andrew
On Mon, Aug 28, 2017 at 7:35 PM, Jay Zhuang
wrote:
> Hi Andrew,
>
> Do yo
I shouldn't actually say I don't think it can happen on 3.0 - I haven't seen
this happen on 3.0 without some other code change to enable it, but like I
said, we're still investigating.
--
Jeff Jirsa
> On Aug 28, 2017, at 8:30 PM, Jeff Jirsa wrote:
>
> For what it's worth, I don't think thi
For what it's worth, I don't think this impacts 3.0 without adding some other
code change (the reporter of the bug on 3.0 had added custom metrics that
exposed a concurrency issue).
We're looking at it on 3.11. I think 13038 made it far more likely to occur,
but I think it could have happened p
We're using 3.0.12+ for a few months and haven't seen the issue like
that. Do we know what could trigger the problem? Or is 3.0.x really
impacted?
Thanks,
Jay
On 8/28/17 6:02 AM, Hannu Kröger wrote:
> Hello,
>
> Current latest Cassandra version (3.11.0, possibly also 3.0.12+) has a race
> condit
Hi Andrew,
Do you mind sharing the backport patch? We're very interested in that,
20-30% improvement sounds great to us.
Thanks,
Jay
On 7/27/17 11:52 PM, Andrew Whang wrote:
> Yes, seeing latency improvement after backporting 9472 to 3.0.13. We are
> measuring p99 latency, thus moving objects of
Hello,
Current latest Cassandra version (3.11.0, possibly also 3.0.12+) has a race
condition that causes Cassandra to create broken sstables (stats file in
sstables to be precise).
Bug described here:
https://issues.apache.org/jira/browse/CASSANDRA-13752
This change might be causing it (but not
