[infinispan-dev] Non-blocking state transfer (ISPN-1424)

Dan Berindei dan.berindei at gmail.com
Fri Mar 9 08:39:47 EST 2012


Hi Galder

First of all, thanks for reading!

On Mar 9, 2012 12:54 PM, "Galder Zamarreño" <galder at redhat.com> wrote:
>
> Hey Dan,
>
> Thanks very much for writing this up! Some questions:
>
> 1. What's "steady state" ? Running status after state transfer has
happened?
>

Exactly, it's when there is no state transfer in progress.

> 2. In L1, I don't understand what you mean in "we do need to add the old
no-longer-owners as requestors for the transferred keys". Do we really need
L1OnRehash? What's the use case/motivation for this option?
>

If we have a put on a new owner, it must know to invalidate the key both on
the nodes that read it after the CH change and the ones that read before
the CH change (from an old owner). It will become critical once we start
staggering clustered get commands.

The L1OnRehash requirement is a bit different, because the old owner wasn't
on any requestor list before the ownership change. But the solution is the
same.

> 3. Recovery cache, just wondering, shouldn't we configure such cache with
a cache store by default? Would that help?
>

I think a cache store would slow things too much, but it would solve this.

> 4. What's the data container snapshot exactly? What kind of impact would
it have on memory consumption?
>

It's not really a snapshot, I just called it a snapshot to convey the idea
that the (Bounded)ConcurrentHashMap doesn't pick up all the changes made
after the start of the iteration.

> One last comment: There's a lot of detail in that wiki which is hard to
fully understand. I think it would really help to build some diagrams
explaining some of the process to help the community understand better your
design, or alternative solutions. WDYT?
>

Fair point. I focused more on keeping track of required code changes to
make sure I don't miss anything, but that ended up being even more dense so
I removed it from the wiki.

Any particular diagram requests, to help prioritize things?

Cheers
Dan

> Cheers,
>
> On Mar 8, 2012, at 10:55 AM, Dan Berindei wrote:
>
> > Hi guys
> >
> > It's been a long time coming, but I finally published the non-blocking
> > state transfer draft on the wiki:
> > https://community.jboss.org/wiki/Non-blockingStateTransfer
> >
> > Unlike my previous state transfer design document, I think I've
> > fleshed out most of the implications. Still, there are some things I
> > don't have a clear solution for yet. As you would expect it's mostly
> > around merging and delayed state transfer.
> >
> > I'm looking forward to hearing your comments/advice!
> >
> > Cheers
> > Dan
> >
> > PS: Let's discuss this over the mailing list only.
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120309/1f96f45c/attachment.html 


More information about the infinispan-dev mailing list