cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Melvin Wang (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-3005) OutboundTcpConnection's sending queue goes unboundedly without any backpressure logic
Date Thu, 11 Aug 2011 22:48:27 GMT


Melvin Wang updated CASSANDRA-3005:

    Attachment: c3005.patch

The goal here is to remove the expired messages as many as we can to avoid the queue going

Two places to do this.
1) when we try to send the message, we drop it if it is already expired. This doesn't work
if the connection is somehow slow because the queue may be piled up already. Thus we have
2) when we enqueue a message we try to remove some expired messages as well. This is tricky
because we now have two threads trying to remove from one queue. Although the operation on
the queue is protected, w/o synchronization, we have enqueue() trying to remove a message
which is not he peeked a moment ago (since it may already be removed from the queue by run()).

To solve this w/o using lock, I use two queues. Whenever run() finishes one queue, it (and
only it) will swap the pointers of queues to process the other one. ConcurrentLinkedQueue
is implemented using a non-block algorithm, so we don't suffer much here.

> OutboundTcpConnection's sending queue goes unboundedly without any backpressure logic
> -------------------------------------------------------------------------------------
>                 Key: CASSANDRA-3005
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Melvin Wang
>            Assignee: Melvin Wang
>         Attachments: 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.
For more information on JIRA, see:


View raw message