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

HotRod client try to unmarhall an object on get() no matter whether the put() use a byte[] or not

    XMLWordPrintable

Details

    • Hide

      See attached project.

      • Client serialize the object and do a put(key, byte[]).
      • as long as the class is available the get return the class (MyValue)
      • if the class is renamed after write the byte[] is returned

      project can be run by
      java -cp target/HotRodSimpleRemoteClient-1.0.jar:$ISPN_LIBS/infinispan-remote-8.0.1.Final.jar infinispan-remote-8.0.1.Final.jar com.bankia.TestMarshall.TestCache

      Show
      See attached project. Client serialize the object and do a put(key, byte[]). as long as the class is available the get return the class (MyValue) if the class is renamed after write the byte[] is returned project can be run by java -cp target/HotRodSimpleRemoteClient-1.0.jar:$ISPN_LIBS/infinispan-remote-8.0.1.Final.jar infinispan-remote-8.0.1.Final.jar com.bankia.TestMarshall.TestCache

    Description

      If a client put an object as byte[] into the cache, which is a self serialized class, the get will return the original class (if it is in the class path) instead of the byte[].
      This is incompatible to ISPN5 here the byte[] is returned in any case.

      It seems this in unintentional due to the smart 'compatibility' mode at client side
      https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/marshall/MarshallerUtil.java#L35

      The client should be able to get the same class type back

      Attachments

        Issue Links

          is caused by

          Bug - A problem that impairs or prevents the functions of the product. ISPN-5180 Hot Rod type converter in Compatibility should not marshall a byte[] again

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed
          relates to

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) ISPN-5357 Hot Rod protocol .NEXT

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • To Do

          Activity

            People

              rh-ee-galder Galder Zamarreño
              rhn-support-wfink Wolf Fink
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: