cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Melvin Wang (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3005) OutboundTcpConnection's sending queue grows unboundedly without any backpressure logic
Date Tue, 01 Nov 2011 23:11:33 GMT

    [ 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

        

Mime
View raw message