[
https://issues.apache.org/jira/browse/CASSANDRA-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803740#action_12803740
]
Jonathan Ellis commented on CASSANDRA-685:
------------------------------------------
Another thought: there is tension between "I want to make the client slow down,
so it stops making things worse by attempting more operations against an
almost-overloaded node" and "if only one node is overloaded for whatever reason
(maybe it is doing compactions and handling bootstrap simultaneously for
instance), I want to be able to continue if my ConsistencyLevel and
ReplicationFactor allow it."
Also: reads are different from writes; a read against an overloaded node may
just be dropped; a write should be HH'd.
> add backpressure to StorageProxy
> --------------------------------
>
> Key: CASSANDRA-685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-685
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.6
>
> Attachments:
> 0001-impose-stage-queue-limit-of-2048-operations-which-shou.txt,
> 0002-make-TcpConnection.write-throw-WriteEnqueueException-i.txt
>
>
> Now that we have CASSANDRA-401 and CASSANDRA-488 there is one last piece: we
> need to stop the target node from pulling mutations out of MessagingService
> as fast as it can only to take up space in the mutation queue and eventually
> fill up memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
