cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Dusbabek (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-1923) unit tests that validate that message serialization isn't broken in the current version.
Date Mon, 24 Jan 2011 16:03:50 GMT

    [ 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.


Mime
View raw message