[
https://issues.apache.org/jira/browse/CASSANDRA-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899482#action_12899482
]
Todd Lipcon commented on CASSANDRA-1214:
----------------------------------------
I don't think it's kosher to pull in LGPL as a build dependency with ivy either
- in Hadoop we dynamically linked some JNI against LZO (LGPL licensed) but it
was decided even that was not allowed, so we had to move the entire LZO support
out to github.
Regarding the FD issue, although reflecting out the FD field isn't that
portable, I've seen it done in an awful lot of places, so I don't think it's
going to change any time soon. There's a patch in the works for Hadoop that
adds some JNI calls for IO-related things, and we grab the fd field there.
There's also an interface sun.misc.JavaIOFileDescriptorAccess which you can
sneak out of sun.misc.SharedSecrets, if that makes you feel better than using
reflection :)
> 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, 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.
