[
https://issues.apache.org/jira/browse/CASSANDRA-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003658#comment-14003658
]
Aleksey Yeschenko commented on CASSANDRA-7231:
----------------------------------------------
My point is that you already have to make similar version-dependent changes in
the driver to support native protocol v3 (collections serialization, for one).
So changing the id from 1 byte to 2 bytes is nothing. You don't even have to
change the ID generator, really, and keep generating [0,127] ids, and only
switch to generating 2-byte ones when you feel like (as a driver author).
It's an extremely tiny change, and is simpler than flags. And yes, a 9 byte
header is uglier than an 8 byte header - but that's not really an argument, if
it has no further consequences (:
Either way, I can live with the flag-way as well - the main point is that one
way or another, the core issue (too many available ids) gets fixed. So I won't
fight the flag-way, but it is my preference that we go the fixed-2 bytes way.
Feel free to override me if you preference is stronger, or involve the
majority, either way it's fine by me.
> 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)
