[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-commits
Subject:    [jira] [Commented] (CASSANDRA-3127) Message (inter-node) compression
From:       "Marcus Eriksson (JIRA)" <jira () apache ! org>
Date:       2012-05-31 11:41:23
Message-ID: 308532344.21482.1338464483764.JavaMail.jiratomcat () issues-vm
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/CASSANDRA-3127?page=com.atlassian.jira.plu \
gin.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

        


[prev in list] [next in list] [prev in thread] [next in thread]