[
https://issues.apache.org/jira/browse/CASSANDRA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965048#action_12965048
]
Jonathan Ellis commented on CASSANDRA-1015:
-------------------------------------------
The next-gen messaging service should also do a better job of avoiding copies
(see: CASSANDRA-1788 for background).
To remove all of these copies, we want to do just one write/read, from object
to socket and back. So Message would take an Object (or an appropriate
interface) body, instead of a byte[]. Then it would ask the object to
serialize itself later, and reform it similarly after the verb type was read.
I started doing this, adding a method to Header like this:
{code}
public ICompactSerializer2 serializerForVerb()
{
switch (verb_)
{
case READ:
return ReadCommand.serializer();
case MUTATION:
case BINARY:
case READ_REPAIR:
return RowMutation.serializer();
case RANGE_SLICE:
return RangeSliceCommand.serializer;
case INDEX_SCAN:
return IndexScanCommand.serializer();
case TRUNCATE:
return Truncation.serializer();
case STREAM_REQUEST:
return StreamRequestMessage.serializer();
case STREAM_REPLY:
return StreamReply.serializer;
case GOSSIP_DIGEST_ACK2:
return GossipDigestAck2Message.serializer();
default:
throw new AssertionError("Unsupported verb " + verb_);
}
}
{code}
But I discovered that many places only know what type of message body is being
sent in the callback that is reading the Message, i.e., we use the
REQUEST_RESPONSE and INTERNAL_RESPONSE verbs for too many different message
types, so at the time that IncomingTcpConnection is reading the Message it does
not know what kind of object to turn the body into. Fixing this is beyond the
scope of what we can reasonably do in 0.7.x so I abandoned it.
(A minor problem that we will also run into is where RowMutationHandler re-uses
the serialized bytes from the Message body to blast to the commitlog. We can
either special case that, or we can re-serialize it once read, which would
still be a win over the status quo.)
> Internal Messaging should be backwards compatible
> -------------------------------------------------
>
> Key: CASSANDRA-1015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1015
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ryan King
> Assignee: Gary Dusbabek
> Priority: Critical
> Fix For: 0.8
>
>
> Currently, incompatible changes in the node-to-node communication prevent
> rolling restarts of clusters.
> In order to fix this we should:
> 1) use a framework that makes doing compatible changes easy
> 2) have a policy of only making compatible changes between versions n and n+1*
> * Running multiple versions should only be supported for small periods of
> time. Running clusters of mixed version is not needed here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
