cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (Updated) (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-3590) Use multiple connection to share the OutboutTCPConnection
Date Tue, 17 Jan 2012 06:04:39 GMT


Vijay updated CASSANDRA-3590:


Finally had a chance to do this bench mark. 

Configuration: M2.4xl (AWS)
Traffic Between: US and EU
Open JDK, CentOS 5.6

3 Tests where done where the active queue is the limiting factor for the traffic to go across
the nodes. Latency is the metric which we are trying to measure in this test (With 1 connection
the latency is high, because of the Delay over the public internet in a AWS multi region setup).

Code for the benchmark is attached with this ticket. 

Server A (US): java -jar Listener.jar 7103
Server B (EU): java -jar RunTest.jar 1 7103 500

Server C (US): java -jar Listener.jar 7103
Server D (EU): java -jar RunTest.jar 2 7103 500

Data is collected with 1 Second interval (plz see code for details).

> Use multiple connection to share the OutboutTCPConnection
> ---------------------------------------------------------
>                 Key: CASSANDRA-3590
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1
>            Reporter: Vijay
>            Assignee: Vijay
>            Priority: Minor
>             Fix For: 1.2
>         Attachments:
> Currently there is one connection between any given host to another host in the cluster,
the problem with this is:
> 1) This can become a bottleneck in some cases where the latencies are higher.
> 2) When a connection is dropped we also drop the queue and recreate a new one and hence
the messages can be lost (Currently hints will take care of it and clients also can retry)
> by making it a configurable option to configure the number of connections and also making
the queue common to those connections the above 2 issues can be resolved.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message