[ https://issues.apache.org/jira/browse/CASSANDRA-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688838#comment-13688838 ]
Ryan McGuire commented on CASSANDRA-5632: ----------------------------------------- I've [written a dtest|https://github.com/riptano/cassandra-dtest/pull/13/files] that automates the testing of this issue. This test clearly shows that the coordinator was talking to more than one node in a different datacenter, and the patch resolves that issue. It also verifies that [~hayato.shimizu]'s comment about using the same forwarder is not happening now. [~jbellis] - I noticed in your [blog post about tracing|http://www.datastax.com/dev/blog/advanced-request-tracing-in-cassandra-1-2] you said not to rely on the activity field, well, that's exactly what I'm doing here. So, +1 to the idea of making those enums so this doesn't break in the future. > 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, 5632-v2.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