cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7231) Support more concurrent requests per native transport connection
Date Mon, 19 May 2014 20:55:38 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002372#comment-14002372
] 

Aleksey Yeschenko commented on CASSANDRA-7231:
----------------------------------------------

TBH, while I see merit in both options, I'm leaning towards the no-flag, version-based option
slightly, now.

1. It saves us a future bit flag
2. It makes the client implementation simpler, esp. a single-version implementation
3. 'in their own time' is not really a good argument here, since there is already an equally
breaking change in the v3 proto that you can't opt out from - new collections encoding format.
We don't have a flag for 'extended collection size', and, logically, this shouldn't require
a flag either, for consistency, if for nothing else.

Separately, but related, I feel like we should make the id unsigned, or at least get rid of
the whole 'negative ids reserved for the server' thing - it's wasteful and unnecessary, even
when talking about 32k vs. 65k range.

> Support more concurrent requests per native transport connection
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-7231
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7231
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 2.1.0
>
>         Attachments: 7231.txt
>
>
> Right now we only support 127 concurrent requests against a given native transport connection.
This causes us to waste file handles opening multiple connections, increases driver complexity
and dilutes writes across multiple connections so that batching cannot easily be performed.
> I propose raising this limit substantially, to somewhere in the region of 16-64K, and
that this is a good time to do it since we're already bumping the protocol version.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message