[ 
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

        

Reply via email to