<p>Hi Galder</p>
<p>First of all, thanks for reading!</p>
<p>On Mar 9, 2012 12:54 PM, "Galder Zamarreņo" <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br>
><br>
> Hey Dan,<br>
><br>
> Thanks very much for writing this up! Some questions:<br>
><br>
> 1. What's "steady state" ? Running status after state transfer has happened?<br>
></p>
<p>Exactly, it's when there is no state transfer in progress.</p>
<p>> 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?<br>
></p>
<p>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.</p>
<p>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.</p>
<p>> 3. Recovery cache, just wondering, shouldn't we configure such cache with a cache store by default? Would that help?<br>
></p>
<p>I think a cache store would slow things too much, but it would solve this.</p>
<p>> 4. What's the data container snapshot exactly? What kind of impact would it have on memory consumption?<br>
></p>
<p>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.</p>
<p>> 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?<br>
></p>
<p>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.</p>
<p>Any particular diagram requests, to help prioritize things?</p>
<p>Cheers<br>
Dan</p>
<p>> Cheers,<br>
><br>
> On Mar 8, 2012, at 10:55 AM, Dan Berindei wrote:<br>
><br>
> > Hi guys<br>
> ><br>
> > It's been a long time coming, but I finally published the non-blocking<br>
> > state transfer draft on the wiki:<br>
> > <a href="https://community.jboss.org/wiki/Non-blockingStateTransfer">https://community.jboss.org/wiki/Non-blockingStateTransfer</a><br>
> ><br>
> > Unlike my previous state transfer design document, I think I've<br>
> > fleshed out most of the implications. Still, there are some things I<br>
> > don't have a clear solution for yet. As you would expect it's mostly<br>
> > around merging and delayed state transfer.<br>
> ><br>
> > I'm looking forward to hearing your comments/advice!<br>
> ><br>
> > Cheers<br>
> > Dan<br>
> ><br>
> > PS: Let's discuss this over the mailing list only.<br>
> > _______________________________________________<br>
> > infinispan-dev mailing list<br>
> > <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> --<br>
> Galder Zamarreņo<br>
> Sr. Software Engineer<br>
> Infinispan, JBoss Cache<br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</p>