On the hashCode violations they are all on
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/Range.java
which
does seem to get the correct hashcode impl from
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/AbstractBounds.java
Jeff
On
Looks like that solves that problem. Probably wouldn't be a bad idea to
include that list in the release posts as well as link to changes.txt? At
the very least it will make us a bit more careful about assigning fix
versions (maybe).
On 1 November 2017 at 00:36, Michael Shuler wrote:
> On 10/31/
On 10/31/2017 07:17 PM, kurt greaves wrote:
> It's usually pretty clear what is a fix in the changes log but they
> definitely require checking. However I'd say putting more boilerplate in
> the changes log isn't really necessary and would be hard to enforce. If we
> could generate a report with th
It's usually pretty clear what is a fix in the changes log but they
definitely require checking. However I'd say putting more boilerplate in
the changes log isn't really necessary and would be hard to enforce. If we
could generate a report with this information from JIRA with desired
information wo
P.S. I am excited to hear about what new hardware can do in this area
compared to existing non-volatile write caches.
On Tue, Oct 31, 2017, at 04:38 PM, Ariel Weisberg wrote:
> Hi,
>
> There are pluggable elements to the commit log such as those used to
> support mmap or compressed.
>
> Can you
I think pluggable commit log is a great idea if we can do it right! 😃
*Especially* given the intent here seems to be motivated by improving endurance
and performance on the given storage you're running C* on. We've actually been
looking at commit log a bunch recently and doing a pretty deep dive
Hi,
There are pluggable elements to the commit log such as those used to
support mmap or compressed.
Can you describe at a high level what a new implementation would look
like and why it can't be a mode of the existing implementation?
You are not proposing changing the format correct?
Regards,
Hello,
We are developing a Cassandra plugin to store CommitLog on our low-latency
Flash device (CAPI-Flash). To do that, the original CommitLog interface
must be changed to allow plugins. Anyone has any thoughts about it? We
have our codebase ready, but we think we should start with high-level
