[infinispan-dev] DIST, state transfer and cache loaders

Dan Berindei dan.berindei at gmail.com
Fri Jun 15 02:43:10 EDT 2012


On Fri, Jun 15, 2012 at 9:18 AM, Bela Ban <bban at redhat.com> wrote:

>
>
> On 6/14/12 7:43 PM, Mircea Markus wrote:
> >
> > ----- Original Message -----
> >> From: "Bela Ban"<bban at redhat.com>
> >> To: infinispan-dev at lists.jboss.org
> >> Sent: Thursday, June 14, 2012 7:20:31 AM
> >> Subject: [infinispan-dev] DIST, state transfer and cache loaders
> >>
> >> It occurred to me that I'm not sure how state transfer happens in
> >> conjunction with cache loaders, can someone confirm that the
> >> statements
> >> below are correct / incorrect ?
> >> Cheers !
> >>
> >> - Say we have {A,B,C,D}, all nodes are configured with a disk-based
> >> (local) cache loader
> >>
> >> - Key K is mapped to A and B
> >>
> >> - After some idle time, K is evicted from A and B
> >>
> >> - Now B leaves
> >>
> >> - A state transfer of some keys (mapped to A) happens to B
> >>
> > I imagine B resurrects at some point here?
>
>
> Sorry, I meant a state transfer from A to C ! (B remains dead)
>
>
> >  If not part of the state is transferred to C (and potentially D if
> virtual nodes are configured).
> >> - As part of the state transfer from A to B, do we iterate through
> >> the
> >> data stored in A's cache loader ?
> >> Â  Â (Because if we only iterated through the in-memory data on A, we'd
> >> not transfer K)
> >
> > yes if you have the fetchPersistentState=true.
>
>
> Even for mode=DIST ?
>
>

Yes, exactly the same in DIST and in REPL.

We first iterate over the data container, and we push all the entries there
(for which we are the last old owner) to their new owners.
Then we iterate over the cache store, ignoring the entries that are already
in the data container, and do the same thing.

Cheers
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120615/69b50503/attachment.html 


More information about the infinispan-dev mailing list