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

Enable inter server endpoint communication in a compatibility mode

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

      Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode.

      Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator.

      When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well).

      For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above.

      May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?).

      In-VM may need registration of an Externalizer?

            [ISPN-2281] Enable inter server endpoint communication in a compatibility mode

            Can someone confirm whether the following is documentation about using this feature:

            http://infinispan.org/docs/6.0.x/infinispan_server_guide/infinispan_server_guide.html#_protocol_interoperability

            If not, I'd appreciate a pointer to the actual notes on how to use this feature instead.

            Misha Ali (Inactive) added a comment - Can someone confirm whether the following is documentation about using this feature: http://infinispan.org/docs/6.0.x/infinispan_server_guide/infinispan_server_guide.html#_protocol_interoperability If not, I'd appreciate a pointer to the actual notes on how to use this feature instead.

            Couple of interesting ideas from a discussion with Tristan:

            1. Allow native types such as byte[] to be used as key directly and instead configure a key Comparator class that determines if two byte[] instances are the same. This would get rid of intermediate wrapper classes.

            2. Cache value metadata to be implemented as an extension to InternalCacheEntry rather than storing it in a wrapper class around the value. Again, this would get rid of unnecessary wrapper classes and would fit into the cache entry architecture providing extra metadata for entries (i.e. last accessed time...etc)

            Galder Zamarreño added a comment - Couple of interesting ideas from a discussion with Tristan: 1. Allow native types such as byte[] to be used as key directly and instead configure a key Comparator class that determines if two byte[] instances are the same. This would get rid of intermediate wrapper classes. 2. Cache value metadata to be implemented as an extension to InternalCacheEntry rather than storing it in a wrapper class around the value. Again, this would get rid of unnecessary wrapper classes and would fit into the cache entry architecture providing extra metadata for entries (i.e. last accessed time...etc)

              rh-ee-galder Galder Zamarreño
              rh-ee-galder Galder Zamarreño
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: