[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7586: ------------------------------------ Description: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients, but at the same time, as the Rolling Upgrade does a put in the target cache from the source cache, it should not trigger a write back to the source cluster. was: We recommend to run the target cluster with a remote-store in mode ready-only during Rolling Upgrades, and point clients from the old cluster to the new one. Clients can see the following situation: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store. -- This message was sent by Atlassian JIRA (v7.2.3#72005)