[
https://issues.apache.org/jira/browse/CASSANDRA-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896473#action_12896473
]
Peter Schuller commented on CASSANDRA-1214:
-------------------------------------------
I'll admit I did not investigate JNA (or POSIX-JNA) for this particular case.
Last time I did however, I found it lacking. Very trivial cases were okay, but
even something as simple as "grab errno" became a holy mess of portability
concerns.
I looked briefly at what posix-jna does, and I was unable to find any magic
bullets in there and instead saw things like hard-coded constants that are
non-portable and difficult to detect when they break due to changes to some
particular platform.
The proposed JNA patch seems to suffer from exactly this problem as far as I
can see, making assumptions about what the concrete values are of MCL_CURRENT
and MCL_FUTURE.
As far as I can tell, once one has gotten over the initial one-time hurdle of
using JNI and the associated building issues, you have a much more
correct/standards-compliant access to the native platform than through JNA
since you're in compile time with access to appropriate headers etc.
Please do correct me if I'm wrong, since the idea of avoiding compile
time/build issues is certainly *very* attractive and the reason why I tried to
find an acceptable solution with JNA in the past.
> Make standard IO the default
> ----------------------------
>
> Key: CASSANDRA-1214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1214
> Project: Cassandra
> Issue Type: Bug
> Reporter: James Golick
> Attachments: 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.
