[jira] [Commented] (CASSANDRA-3005) OutboundTcpConnection's sending queue grows unboundedly without any backpressure logic

["Melvin Wang (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141737#comment-13141737 ] 

Melvin Wang commented on CASSANDRA-3005:
----------------------------------------

ok, i cannot say for sure that ConcurrentLinkedQueue performs better than LinkedBlockingQueue. v4 and v3 differs mainly in the underlying queue implementation which is not hard to change if it is a bottleneck. And I agree that in run() ConcurrentLinkedQueue + condition variable does look like a blocking queue, so we can settle this. :)  There is only one thing. Can we just append the element to 'active' rather than push back to 'backlog' in expireMessage? The reason (as I understand) is to save one round of racing to gain the lock to the beginning of 'backlog' because you need to race to get the lock to push at the beginning of queue then multiple threads will race to remove elements from the beginning of the queue as well (to expire messages), whereas you just race once to get the element to the end of 'active' which will remove elements in a single thread.
                
> 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-v4, 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