<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 28, 2014 at 7:35 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 28 July 2014 17:24, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
> 1. Configuration inheritance: I would go further and allow the definition of<br>
> "configurations" that cannot be started, only inherited from.<br>
> 2. Replication queue: I discussed an upgrade to the replication queue with<br>
> Will, similar to JGroups' TransferQueuBundler [1]. It does raise an<br>
> interesting point about why we need the same functionality both in JGroups<br>
> and in Infinispan, though...<br>
> 3. I think ClusterLoader is still useful in invalidation mode, and also<br>
> replication mode w/out state transfer ("lazy" state transfer).<br>
<br>
</div>What's the use case for asking for REPL but not caring for actual REPL?<br>
In such use case I expect data to be either very uninportant (other<br>
than performance-wise) or persisted to a shared cachestore: I'd use<br>
Invalidation, L1 and maybe even disable state transfer.<br></blockquote><div><br></div><div>Invalidation mode doesn't have L1, ClusterLoader is the closest equivalent.</div><div><br></div><div>I'm guessing replication - state transfer + ClusterLoader would perform more or less like regular replication + state transfer, but without the delay when bringing up a new node. Invalidation mode has the downside that application writes invalidate the key on all nodes, so the next read for that key will be slow.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Sanne<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> [1] <a href="https://issues.jboss.org/browse/ISPN-4547" target="_blank">https://issues.jboss.org/browse/ISPN-4547</a><br>
><br>
> Cheers<br>
> Dan<br>
><br>
><br>
><br>
> On Mon, Jul 28, 2014 at 6:04 PM, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Tristan, Sanne, Gustavo and I meetlast week to discuss a) Infinispan<br>
>> usability and b) monitoring and management. Minutes attached.<br>
>><br>
>><br>
>> <a href="https://docs.google.com/document/d/1dIxH0xTiYBHH6_nkqybc13_zzW9gMIcaF_GX5Y7_PPQ/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1dIxH0xTiYBHH6_nkqybc13_zzW9gMIcaF_GX5Y7_PPQ/edit?usp=sharing</a><br>
>><br>
>> Cheers,<br>
>> --<br>
>> Mircea Markus<br>
>> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
>><br>
>><br>
>><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" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><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" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><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" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>