[ 
https://issues.apache.org/jira/browse/CASSANDRA-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286493#comment-13286493
 ] 

Marcus Eriksson commented on CASSANDRA-3127:
--------------------------------------------

I have not (yet) tried Snappy for this, should i?

new patch does what you suggest, approach when node A starts communicating with 
node B is:
# node A sends the first message uncompressed, but with the compression bit set 
in the header (this is only done if it is enabled in the conf and the version 
of node B is >= current, but since MessagingService returns current version if 
it does not know about the remote node, not sure how effective it is, guess we 
get an exception and a reconnect, and then we might know the remote version)
# node A "upgrades" its dataoutputstream to be compressed
# node B gets the first, uncompressed message, sees the compression flag in the 
header and upgrades the DataInputStream to be compressed
                
> Message (inter-node) compression
> --------------------------------
>
>                 Key: CASSANDRA-3127
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3127
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sylvain Lebresne
>            Assignee: Marcus Eriksson
>            Priority: Minor
>         Attachments: 
> 0001-CASSANDRA-3127-compress-messages-between-nodes.patch, 
> CASSANDRA-3127.patch, CHECK_SIZES-CASSANDRA-3127.patch
>
>
> CASSANDRA-3015 adds compression of streams. But it could be useful to also 
> compress some messages.
> Compressing messages is easy, but what may be little bit trickier is when and 
> what messages to compress to get the best performances.
> The simple solution would be to just have it either always on or always off. 
> But for very small messages (gossip?) that may be counter-productive. On the 
> other side of the spectrum, this is likely always a good choice to compress 
> for say the exchange of merkle trees across data-centers. We could maybe 
> define a size of messages after which we start to compress. Maybe the option 
> to only compress for cross data-center messages would be useful too (but I 
> may also just be getting carried away). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to