[
https://issues.apache.org/jira/browse/CASSANDRA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756122#action_12756122
]
Jonathan Ellis commented on CASSANDRA-401:
------------------------------------------
02
clean out unused code from MessagingService. Inline sink processing into
sendOneWay instead of having another exe
this sets the stage for backpressuring the client, should we choose to do
that
01
support multiple flush threads safely. automatically use up to avaiable
core count threads for
flushing. pause updates when too many unflushed memtables are generated.
Note that I'm not actually adding backpressure here: on further thought, it
seems like the worst of both worlds. No matter what we do on the sending side,
we can't tell ahead of time if the receiving node is going to start blocking
while waiting to apply the mutation. So backpressure would mean having to deal
with both UnavailableException, and potentially unbounded wait times. Without
it we just have to deal w/ the former case.
> Less crappy failure mode when swamped with inserts than "run out of memory
> and gc-storm to death"
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-401
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-401.txt,
> 0002-clean-out-unused-code-from-MessagingService.-Inline-si.txt,
> screenshot-1.jpg
>
>
> Suggestion was made that
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryPoolMXBean.html#setCollectionUsageThreshold(long)
> is relevant. Correlation eludes me, but I Am Not A Java Expert. :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
