[ https://issues.jboss.org/browse/ISPN-4343?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-4343: ------------------------------------ [~mgencur] [~NadirX] you might be interested: I left our testsuite and tried manual set up -- 2 old servers and 2 new servers, clustered: 1) put 5 entries via CLI into *old1* [put --codec=rest default.key1 value1] 2) verify entries are replicated to *old2* and accessible (ok) [get --codec=rest default.key1] -- returned value1 -- OK! 3) try to remotely get key1 issuing get on *new1* [get --codec=rest default.key1] -- returned *"[B cannot be cast to org.infinispan.remoting.MIMECacheEntry"* -- see attached *cannot_be_cast.txt* for full log 4) *new1* fetched this one entry from REST remote cache store (*old1*) -- OK (but can't read it properly) 5) issue *synchronize-data* operation on *new1* using jconsole -- returned 5 - this is OK, server replied: 10:19:11,716 INFO org.infinispan.upgrade.RollingUpgradeManager (RMI TCP Connection(5)-127.0.0.1) ISPN000216: *5 entries migrated to cache default* in 74 milliseconds -- and really, 5 entries was migrated, statistics says 5 entries in a default cache, *new1* 6) try to obtain values from migrated entries [get --codec=rest key1] -- returned "[B cannot be cast to org.infinispan.remoting.MIMECacheEntry" -- see attached cannot_be_cast.txt for full log Adding a link to: https://issues.jboss.org/browse/ISPN-4200 Summary: the process of rest rolling upgrades work fine even with clustered environment. However, after migration, we are unable to successfully decode entries and read values on *new* nodes. It seems the problem occurs for both CLI and example configuration test. We need to solve that decoding issue for having REST rolling upgrades working properly. -- This message was sent by Atlassian JIRA (v6.2.6#6264)