[jira] Issue Comment Edited: (CASSANDRA-401) Less crappy failure mode when swamped with inserts than "run out of memory and gc-storm to death"

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756122#action_12756122 ] 

Jonathan Ellis edited comment on CASSANDRA-401 at 9/16/09 10:38 AM:
--------------------------------------------------------------------

02
    clean out unused code from MessagingService. Inline sink processing into sendOneWay instead of having another executor.
    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.

      was (Author: jbellis):
    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.