[ 
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

Reply via email to