[
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)
