[
https://issues.apache.org/jira/browse/CASSANDRA-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686828#comment-13686828
]
Jonathan Ellis commented on CASSANDRA-5632:
-------------------------------------------
.55 is the forwarding node in DC2. It logs that it applies the mutation and
acks it:
{noformat}
Enqueuing response to /192.168.56.50 | 05:57:33,825 | 192.168.56.55 |
14785
{noformat}
But there is no "Processing response from /192.168.56.55" line logged by .50.
Hmm.
> Cross-DC bandwidth-saving broken
> --------------------------------
>
> Key: CASSANDRA-5632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5632
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.2.6
>
> Attachments: 5632.txt, cassandra-topology.properties,
> fix_patch_bug.log
>
>
> We group messages by destination as follows to avoid sending multiple
> messages to a remote datacenter:
> {code}
> // Multimap that holds onto all the messages and addresses meant for
> a specific datacenter
> Map<String, Multimap<Message, InetAddress>> dcMessages
> {code}
> When we cleaned out the MessageProducer stuff for 2.0, this code
> {code}
> Multimap<Message, InetAddress> messages =
> dcMessages.get(dc);
> ...
>
> messages.put(producer.getMessage(Gossiper.instance.getVersion(destination)),
> destination);
> {code}
> turned into
> {code}
> Multimap<MessageOut, InetAddress> messages =
> dcMessages.get(dc);
> ...
> messages.put(rm.createMessage(), destination);
> {code}
> Thus, we weren't actually grouping anything anymore -- each destination
> replica was stored under a separate Message key, unlike under the old
> CachingMessageProducer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
