[
https://issues.apache.org/jira/browse/CASSANDRA-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1214:
--------------------------------------
Attachment: 1214-v4.txt
v4 includes the ivy changes to download jna at build time.
Again, the relevant text from http://www.apache.org/legal/3party.html is, "LGPL
v2.1-licensed works must not be included in Apache products, although they may
be listed as system requirements or distributed elsewhere as optional works."
We are not including jna, nor are we even requiring it [although it explicitly
states it would be fine to do so]. The only restriction is on distributing the
lgpl work itself, so while Hadoop is welcome to pile additional restrictions on
themselves this is fine for us, since (and perhaps this wasn't clear)
dependencies we pull in with ivy are build-time only, and are not distributed
with our source or binary artifacts.
(FWIW it is also fine for an apache-licensed debian package, to declare a
dependency on an lgpl one.)
> Force linux to not swap the JVM
> -------------------------------
>
> Key: CASSANDRA-1214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1214
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: James Golick
> Fix For: 0.6.5
>
> Attachments: 1214-v3.txt, 1214-v4.txt, mlockall-jna.patch.txt, Read
> Throughput with mmap.jpg, trunk-1214.txt
>
>
> The way mmap()'d IO is handled in cassandra is dangerous. It allocates
> potentially massive buffers without any care for bounding the total size of
> the program's buffers. As the node's dataset grows, this *will* lead to
> swapping and instability.
> This is a dangerous and wrong default for a couple of reasons.
> 1) People are likely to test cassandra with the default settings. This issue
> is insidious because it only appears when you have sufficient data in a
> certain node, there is absolutely no way to control it, and it doesn't at all
> respect the memory limits that you give to the JVM.
> That can all be ascertained by reading the code, and people should certainly
> do their homework, but nevertheless, cassandra should ship with sane defaults
> that don't break down when you cross some magic unknown threshold.
> 2) It's deceptive. Unless you are extremely careful with capacity planning,
> you will get bit by this. Most people won't really be able to use this in
> production, so why get them excited about performance that they can't
> actually have?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
