[infinispan-dev] Rolling upgrades improvement proposal
Manik Surtani
msurtani at redhat.com
Wed Feb 13 05:05:20 EST 2013
During a push, wouldn't you hit consistency issues with ongoing (applictaion-initiated) writes on the new cluster?
On 13 Feb 2013, at 09:09, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Hi all,
>
> the current implementation of rolling upgrades is lacking in a few areas which I think warrant urgent attention in the scope of JDG 6.1 (i.e. for the 5.2.x-cycle):
>
> support for rolling upgrades from JDG 6.0.x to JDG 6.1.x
> efficiency of the bulk key synchronization (all keys are serialized into a single key which the target cluster uses to *suck* all data from the source cluster).
>
> During the Infinispan 5.2 cycle I added support in RemoteCache+RemoteCacheStores to be able to fetch the entries complete with metadata (i.e. expiration/maxIdle). Unfortunately this feature is not available in Infinispan 5.1, and therefore the implementation may only be able to fetch naked key/values, losing mortality information.
> To partially overcome this issue, and also to solve the above efficiency issue, I would like the synchronization phase of the rolling upgrade to be a push operation from the source cluster to the target cluster: instead of dumping the keyset into a single key, the source cluster would initiate a distributed task which would cycle through the entire keyset and PUT to the target cluster complete with the correct expiration information (if the source cluster uses JDG 6.1 this could probably be a GET, which would trigger the usual getWithMetadata).
>
> Comments, thoughts.
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130213/692ea60b/attachment.html
More information about the infinispan-dev
mailing list