[
https://issues.apache.org/jira/browse/CASSANDRA-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13137823#comment-13137823
]
Jonathan Ellis commented on CASSANDRA-3005:
-------------------------------------------
bq. 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.
Here's the problem:
{noformat}
+ Entry entry = producer.peek();
+ if (entry == null)
+ break;
+ if (entry.timestamp + DatabaseDescriptor.getRpcTimeout() <
System.currentTimeMillis()) {
+ if (producer.poll() == null)
+ break; // consumer swaps the pointers so we end up
having an empty queue here.
+ }
{noformat}
poll() may be an unexpired entry, not the one peeked, if the sending thread
switched queues and also took the front entry off in between the peek and the
poll. In other words: you still have the same problem you had to start with,
just more subtle.
bq. The point of this design is that we don't need to lock the queues whereas
BlockingQueue/Deque locks it
Producer/consumer is what the concurrent.Blocking classes are designed for.
The "Blocking" means you can call take() and it will block until an entry is
ready, not that it generates a lot of contention.
> 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
