[
https://issues.apache.org/jira/browse/CASSANDRA-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melvin Wang updated CASSANDRA-3005:
-----------------------------------
Attachment: c3005.patch
The goal here is to remove the expired messages as many as we can to avoid the
queue going unbounded.
Two places to do this.
1) when we try to send the message, we drop it if it is already expired. This
doesn't work if the connection is somehow slow because the queue may be piled
up already. Thus we have
2) when we enqueue a message we try to remove some expired messages as well.
This is tricky because we now have two threads trying to remove from one queue.
Although the operation on the queue is protected, w/o synchronization, we have
enqueue() trying to remove a message which is not he peeked a moment ago (since
it may already be removed from the queue by run()).
To solve this w/o using lock, I use two queues. Whenever run() finishes one
queue, it (and only it) will swap the pointers of queues to process the other
one. ConcurrentLinkedQueue is implemented using a non-block algorithm, so we
don't suffer much here.
> OutboundTcpConnection's sending queue goes unboundedly without any
> backpressure logic
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-3005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3005
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Melvin Wang
> Assignee: Melvin Wang
> Attachments: c3005.patch
>
>
> OutboundTcpConnection's sending queue unconditionally queues up the request
> and process them in sequence. Thinking about tagging the message coming in
> with timestamp and drop them before actually sending it if the message stays
> in the queue for too long, which is defined by the message's own time out
> value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
