cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8457) nio MessagingService
Date Wed, 17 Dec 2014 15:02:14 GMT


Benedict commented on CASSANDRA-8457:

bq. The only way to avoid it is to lock while checking the queue empty condition and updating
the needs wakeup field, or to have a 1:1 mapping between sockets and dispatch threads (AKA
not SEP). This would force producers to lock on task submission as well. I don't see how the
dispatch task can atomically check that there is no work to do and set the needs wakeup flag
at the same time. At that point is there a reason to use a lock free queue?

    private Runnable dispatchTask = new Runnable() {
        public void run() {
            while (true)
                while (!backlog.isEmpty()) 

                needsWakeup = true;
                if (backlog.isEmpty() || !needsWakeupUpdater.compareAndSet(OutboundTcpConnection.this,

> nio MessagingService
> --------------------
>                 Key: CASSANDRA-8457
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Ariel Weisberg
>              Labels: performance
>             Fix For: 3.0
> Thread-per-peer (actually two each incoming and outbound) is a big contributor to context
switching, especially for larger clusters.  Let's look at switching to nio, possibly via Netty.

This message was sent by Atlassian JIRA

View raw message