[ 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