[
https://issues.apache.org/jira/browse/CASSANDRA-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13137711#comment-13137711
]
Melvin Wang commented on CASSANDRA-3005:
----------------------------------------
bq. v2 still has a race if the sending thread swaps the queues between the peek
and the poll in expire.
I don't think it is a race per se. If the sending thread swaps the two queues,
we then stop expiring messages and break. If it doesn't, then 'producer' is
still pointing to the instance from which we peek. If the message we peek is
meant be expired, and the sending thread swaps the queues, it will be dropped
in run() anyway. The queues will only be swapped once 'consumer' is empty, i.e.
nothing to send to the network.
The point of this design is that we don't need to lock the queues whereas
BlockingQueue/Deque locks it). The goal is to be lock-free.
> OutboundTcpConnection's sending queue grows 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: 3005-v3.txt, c3005-v2, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
