cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7231) Support more concurrent requests per native transport connection
Date Thu, 22 May 2014 22:45:02 GMT


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 ==
- 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:
>             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

View raw message