cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3005) OutboundTcpConnection's sending queue grows unboundedly without any backpressure logic
Date Fri, 28 Oct 2011 01:39:32 GMT


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:

+            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.
+            }

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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message