[
https://issues.apache.org/jira/browse/CASSANDRA-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14317003#comment-14317003
]
Benedict commented on CASSANDRA-8789:
-------------------------------------
bq. relaxing ordering guarantees is one of those things you want to opt into.
We don't really have any ordering guarantees here. Currently we have single
request-response rounds, with the entirety of each being encoded in a single
message. Even if we didn't, the way we accumulate message results on the
coordinator is to wait until they all arrive then combine the results, so it
would still be fine. In the medium term we want to introduce streaming
reads/writes, at which point we won't need any separate connection at all,
since we can split each message up into bite size chunks below our maximum, and
interleave them with the other messages. In the meantime I don't see any
significant downside to this approach. It does potentially mean that a higher
bandwidth allocation will be assigned to huge messages, but that's probably for
the best anyway. They'll utilise bandwidth better, and we want them out of the
VMs ASAP to reduce the temporary burden they impose.
Besides, as [~jbellis] says, we're improving well behaved users with these
considerations only affecting the naughty ones.
> Revisit how OutboundTcpConnection pools two connections for different message
> types
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-8789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8789
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Fix For: 3.0
>
>
> I was looking at this trying to understand what messages flow over which
> connection.
> For reads the request goes out over the command connection and the response
> comes back over the ack connection.
> For writes the request goes out over the command connection and the response
> comes back over the command connection.
> Reads get a dedicated socket for responses. Mutation commands and responses
> both travel over the same socket along with read requests.
> Sockets are used uni-directional so there are actually four sockets in play
> and four threads at each node (2 inbounded, 2 outbound).
> CASSANDRA-488 doesn't leave a record what the impact of this change was. If
> someone remembers what situations were made better it would be good to know.
> I am not clear on when/how this is helpful. The consumer side shouldn't be
> blocking so the only head of line blocking issue is the time it takes to
> transfer data over the wire.
> If message size is the cause of blocking issues then the current design mixes
> small messages and large messages on the same connection retaining the head
> of line blocking.
> Read requests share the same connection as write requests (which are large),
> and write acknowledgments (which are small) share the same connections as
> write requests. The only winner is read acknowledgements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
