[
https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985764#action_12985764
]
Gary Dusbabek edited comment on CASSANDRA-1923 at 1/24/11 11:03 AM:
--------------------------------------------------------------------
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.
was (Author: gdusbabek):
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.
