[
https://issues.apache.org/jira/browse/CASSANDRA-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006557#comment-14006557
]
Aleksey Yeschenko commented on CASSANDRA-7231:
----------------------------------------------
Okay. As far as the code goes, I only see two issues:
- the check in Header constructor is broken for server-initiated events (-1 &
0xFF == 0xFF)
- in decode(), 'streamId &= (buffer.getByte(bodyStart) & 0xFF);' should be
'streamId |= buffer.getByte(bodyStart);'
Also attached a patch with a bit of doc fixes.
Really though, I do feel bad for flip-flopping like this (suggesting the fixed
2-byte version first, then agreeing with flag-based approach, and then pushing
for fixed 2-byte version again), but, in my defense, I was assuming a different
flag-based approach.
Namely, that with EXTENDED_STREAM_ID flag set, we'd just have a 2-byte id in
the 9-byte header, and simply have writeShort()/readShort() calls instead of
writeByte()/readByte() in encode()/decode(), respectively. I'd still have a
minor preference for a fixed 2-byte stream id, but very, very minor in that
case.
But the approach in this v1 I don't like - it's a bit too complex and hackish.
If you don't feel like cooking up another patch for this, I'll do it, with
either approach (1 - fixed 2-bytes or 2 - 8/9 bytes header depending on the
flag, described above), assuming that you don't disagree on principle
[~slebresne] [~thobbs]
> 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, v1-doc-fixes.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)
