Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-9620

In-place Rolling Upgrade Marshaller Changes

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • 9.4.0.Final
    • Core, Loaders and Stores
    • None
    • Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #39

      In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation.

          1.
          		 Replace external marshaller with user marshaller Sub-task Closed Major Ryan Emerson
          2.
          		 Split global marshaller into Persistence and Internal marshaller Sub-task Closed Major Ryan Emerson
          3.
          		 Replace GlobalMarshaller with protobuf based marshaller Sub-task Closed Major Ryan Emerson
          4.
          		 Create Protobuf based user marshaller Sub-task Closed Major Ryan Emerson
          5.
          		 Deprecate StreamingMarshaller interface Sub-task Closed Major Ryan Emerson
          6.
          		 Make MarshalledEntryImpl private and utilise MarshalledEntryFactory instead Sub-task Closed Major Ryan Emerson
          7.
          		 Stop exposing InternalMetadata via the persistence SPI Sub-task Closed Major Ryan Emerson
          8.
          		 Ensure Backwards Compatibility with Persistence SPI changes Sub-task Closed Major Ryan Emerson
          9.
          		 Add build step to check protobuf schema changes are backwards compatible Sub-task Closed Major Ryan Emerson
          10.
          		 Adapt StoreMigrator to support Infinispan 8-10 marshallers Sub-task Closed Major Ryan Emerson
          11.
          		 Deprecate org.infinispan.commons.marshall.Externalizer and @SerializeWith Sub-task Closed Major Ryan Emerson
          12.
          		 Introduce `.impl` package for internal marshalling classes Sub-task Closed Major Ryan Emerson
          13.
          		 Remove jboss-marshalling dependency from core Sub-task Closed Major Ryan Emerson
          14.
          		 Remove ExternalPojo Interface and ExternallyMarshallable Sub-task Closed Major Ryan Emerson
          15.
          		 Allow multiple SerializationContextInitializers to be provided via configuration Sub-task Closed Major Ryan Emerson
          16.
          		 Update Marshalling documentation and upgrade notes Sub-task Closed Major Ryan Emerson
          17.
          		 Utilise TYPE_ID_ANNOTATION for known internal types Sub-task Closed Major Ryan Emerson
          18.
          		 Remove UserMarshallerWhiteList Sub-task Closed Major Ryan Emerson
          19.
          		 Provide Externalizer aware Serialization marshaller as default user marshaller Sub-task Closed Major Ryan Emerson
          20.
          		 Remove jboss-marshalling and make Protostream the default user marshaller Sub-task Closed Major Ryan Emerson
          21.
          		 Deprecate JBossUserMarshaller and associated classes Sub-task Closed Major Ryan Emerson

            [ISPN-9620] In-place Rolling Upgrade Marshaller Changes

            Tristan Tarrant added a comment -

            Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues
            If you still want this issue to be worked on, create a new issue on GitHub and link this issue.

            Tristan Tarrant added a comment - Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues If you still want this issue to be worked on, create a new issue on GitHub and link this issue.

            Ryan Emerson added a comment -

            gfernand@redhat.com This is built upon what was discussed at last years F2F. It is a long term goal we're working towards and does not intend to replace the current rolling upgrades that we have. The idea is that we get to the stage where we can do the following types of upgrade:

            1. Offline upgrade (start/stop). Cache stores are dumped using the old ISPN cluster, new ISPN cluster brought up using the old date.
            2. Kuberenetes Rolling updates. This is the long term goal, which requires more than marshalling changes, e.g. versioned interceptor stacks. The marshalling changes are required in this context to allow over the air compatibility between ISPN versions.

            Ryan Emerson added a comment - gfernand@redhat.com This is built upon what was discussed at last years F2F. It is a long term goal we're working towards and does not intend to replace the current rolling upgrades that we have. The idea is that we get to the stage where we can do the following types of upgrade: Offline upgrade (start/stop). Cache stores are dumped using the old ISPN cluster, new ISPN cluster brought up using the old date. Kuberenetes Rolling updates . This is the long term goal, which requires more than marshalling changes, e.g. versioned interceptor stacks. The marshalling changes are required in this context to allow over the air compatibility between ISPN versions.

            Gustavo Fernandes (Inactive) added a comment - - edited

            "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation."

            Is about a core-scoped rolling upgrade? Or related to the current Rolling Upgrade that happens over hot rod?

            For the current procedure, a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc.
            When migrating data from a cluster to another, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format, so it does not make sense to use the same marshaller between two clusters

            Gustavo Fernandes (Inactive) added a comment - - edited "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation." Is about a core-scoped rolling upgrade? Or related to the current Rolling Upgrade that happens over hot rod? For the current procedure, a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc. When migrating data from a cluster to another, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format, so it does not make sense to use the same marshaller between two clusters

              remerson@redhat.com Ryan Emerson
              remerson@redhat.com Ryan Emerson
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: