[
https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985764#action_12985764
]
Gary Dusbabek commented on CASSANDRA-1923:
------------------------------------------
bq: 1: what bugs will this catch, that patch 3 will not?
1 will fail if somebody creates a new class that implements ICompactSerializer
or removes an existing implementation, both of which have the capability to
break compatibility in minor releases.
bq: Is there an actual need to change this?
Yes. Usage outside of the package would require making MessageSerializer a
proper inner class. (Still, I think exposing MessageSerializer is leaky.)
bq: 6: probably doesn't belong on this ticket, and the bounce should be
unnecessary w/ the proposed solution on CASSANDRA-1970
I can move it to 1970, but I still think we need it. The solution proposed
there is a way to track protocol versions across nodes. When a new node
contacts an old node, we still have no guarantee that the old node can properly
deserialize the message body.
> unit tests that validate that message serialization isn't broken in the
> current version.
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-1923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1923
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Gary Dusbabek
> Assignee: Gary Dusbabek
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments:
> v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt,
> v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt,
> v2-0003-Serialization-tests.txt,
> v2-0004-build-changes-to-run-serialization-tests.txt,
> v2-0005-0.7-message-serialization-test-binaries.txt,
> v2-0006-bounce-messages-from-newer-versions.txt
>
>
> There are two components to this. First, code that will generate the
> serialized messages. Second, code that will attempt to read the serialized
> messages.
> My plan is to commit this to 0.7.1 with generated serialized messages. Then
> I will merge that into trunk sans the generation code. A similar process
> will need to take place when we branch trunk to create 0.8, etc. On second
> thought, maybe it makes sense to keep the generation code and let it morph as
> the message formats change.
> If the tests ever break in the 0.7 branch, that means we've created a message
> incompatibility regression that needs to be fixed. If the tests ever break
> in trunk (post CASSANDRA-1015), it means that something in trunk has changed
> message serialization compatibility that will need to be restored (via
> whatever process is used for 1015).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
