You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2019/09/03 18:08:00 UTC

[jira] [Commented] (GEODE-7090) Remove dependency on DataSerializer from membership classes

    [ https://issues.apache.org/jira/browse/GEODE-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16921627#comment-16921627 ] 

ASF subversion and git services commented on GEODE-7090:
--------------------------------------------------------

Commit 4cd3f3b907e79da2152e798e0c54fd58b82caa5d in geode's branch refs/heads/feature/GEODE-7090 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4cd3f3b ]

GEODE-7090 Remove dependency on DataSerializer from membership classes

DataSerializableFixedID is used by most internal classes for
serialization.  Membership, in particular, was constrained in its
implementation to use only "fixed" serialization identifiers because our
other serialization mechanisms (DataSerialiable, PDX) are dependent on
membership and messaging.

This PR moves serialization of DataSerializableFixedID to a new
sub-project, geode-serialization in support of also separating
membership into its own sub-project.

Many files are touched by this PR.  The vast majority are due to a
change in the serialization interface that introduces a new parameter in
DataSerializableFixedID's toData and fromData methods.  This parameter
gives access to the serializer and to the Version of the
source/destination.  This parameter was added to begin moving from a
"static" based serialization service to an instance based service.

Serialization code concerning "DSFID"s has been moved from
InternalDataSerializer to the new class DSFIDSerialzerImpl.
InternalDataSerializer holds on to an instance of this class and
delegates DSFID serialization to it.

InternalDataSerializer also effects registration of Geode's DSFID
classes with this serializer.  Membership "Services" handles
registration of its own DSFID classes with the service, as do other
sub-projects like geode-web.

HeapDataOutputStream has been used by most of our serialization code to
provide a DataOutput for our toData methods.  Over the years this class
has accumulated a lot of adornments for PDX serialization that aren't
appropriate for a geode-serialization sub-project.  Consequently I've
moved much of its code into a superclass, BufferDataOutputStream, that
provides most of its functionality w/o needing to reference other geode-
core classes.

Version.java has been repackaged in this PR, moving it into a
"serialization" package.  This affected some rolling-upgrade and
backward-compatibility tests that were referring to
Version.CURRENT_ORDINAL.  These have been modified to get the "current
version ordinal" from VersionManager.

Finally, InternalDataSerializer injects a serializer into the new
sub-project that provideds an API for handling other types of
serializable objects like PDX.  This serializer is available in the
DataSerializableFixedID toData/fromData context parameter and is used by
membership services when serializing Geode DistributionMessages.

I don't think most of the files deserve scrutiny.  The primary files
affected are InternalDataSerializer and DSFIDFactory. Aside from that,
does the new SerializationContext API make sense?  Could it be improved?


> Remove dependency on DataSerializer from membership classes
> -----------------------------------------------------------
>
>                 Key: GEODE-7090
>                 URL: https://issues.apache.org/jira/browse/GEODE-7090
>             Project: Geode
>          Issue Type: Sub-task
>          Components: membership
>            Reporter: Bruce Schuchardt
>            Assignee: Bruce Schuchardt
>            Priority: Major
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.2#803003)