[
https://issues.apache.org/jira/browse/CASSANDRA-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511879#comment-14511879
]
Ariel Weisberg edited comment on CASSANDRA-8789 at 4/24/15 10:09 PM:
---------------------------------------------------------------------
[~xedin] I tried to reproduce what Michael described and I found a root cause
that is different and it seems to be an issue across multiple versions, both
with and without the changes to OTCP. IOW I think it is unrelated to this
ticket.
It's definitely worth reproducing the problem Michael is talking about which is
why I created a ticket for that specific issue. AFAIK no one besides myself has
tested with and without this change on trunk and found that it has an impact.
[~mkjellman] if you try and run this using your reproducer steps if you let it
hang long enough do you get the heap dump and OOM? If you revert the change are
you saying everything starts to work for you?
was (Author: aweisberg):
[~xedin] I tried to reproduce what Michael described and I found a root cause
that is different and it seems to be an issue across multiple versions. IOW I
think it is unrelated to this ticket.
It's definitely worth reproducing the problem Michael is talking about which is
why I created a ticket for that specific issue. AFAIK no one besides myself has
tested with and without this change on trunk and found that it has an impact.
[~mkjellman] if you try and run this using your reproducer steps if you let it
hang long enough do you get the heap dump and OOM? If you revert the change are
you saying everything starts to work for you?
> OutboundTcpConnectionPool should route messages to sockets by size not type
> ---------------------------------------------------------------------------
>
> 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
>
> Attachments: 8789.diff
>
>
> 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 of 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)
