<div dir="ltr"><div style><span style="font-family:arial,sans-serif;font-size:13px">>Would the L1 data container be a "separate, but equal" container? i.e.</span><br></div><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">would it be a separate instance from the DIST_SYNC cache but the exact same</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">data structure?</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">or</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">Would the L1 data container be "separate, and different" container? i.e.</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">would it be a completely different data structure (and API) from the</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">DIST_SYNC cache?</span><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Currently it would be using the same implementation and interface behind the scenes. My initial thought is that it would always use the same interface, but we could add a specific implementation later if we found additional optimizations.<br>
</font><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 9:34 AM, Pedro Ruivo <span dir="ltr"><<a href="mailto:pedro@infinispan.org" target="_blank">pedro@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
+1 :)<br>
<br>
some comments inline.<br>
<br>
Pedro<br>
<div class="im"><br>
On 06/19/2013 02:16 PM, Manik Surtani wrote:<br>
> I have often thought of this. Comments inline:<br>
><br>
> On 19 Jun 2013, at 13:44, William Burns <<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a>>> wrote:<br>
><br>
>> All the L1 data for a DIST cache is stored in the same data container<br>
>> as the actual distributed data itself. I wanted to propose breaking<br>
>> this out so there is a separate data container for the L1 cache as<br>
>> compared to the distributed data.<br>
>><br>
>> I thought of a few quick benefits/drawbacks:<br>
>><br>
>> Benefits:<br>
>> 1. L1 cache can be separately tuned - L1 maxEntries for example<br>
<br>
</div>+1 for the maxEntries. I think the L1 should be always bounded to avoid<br>
any memory issues<br></blockquote><div style>+1 always having it be bounded would be really good. The configuration could have a default and there could be a check to make sure they have > 1 configured if provided. I don't know what would be the best default here though? 64? 128? 1024?</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
>> 2. L1 values will not cause eviction of real data<br>
>> 3. Would make <a href="https://issues.jboss.org/browse/ISPN-3229" target="_blank">https://issues.jboss.org/browse/ISPN-3229</a> an easy fix<br>
>> 4. Could add a new DataContainer implementation specific to L1 with<br>
>> additional optimizations<br>
>> 5. Help with some concurrency issues with L1 without requiring wider<br>
>> locking (such as locking a key for an entire ClusteredGet rpc call) -<br>
>> <a href="https://issues.jboss.org/browse/ISPN-3197" target="_blank">https://issues.jboss.org/browse/ISPN-3197</a>.<br>
>><br>
>> Drawbacks:<br>
>> 1. Would require, depending on configuration, an additional thread for<br>
>> eviction<br>
><br>
> Not really - the same eviction thread used for the main data container<br>
> could also clean things up in the L1 DC.<br></div></blockquote><div style>+1</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
><br>
>> 2. Users upgrading could have double memory used up due to 2 data<br>
>> containers<br>
><br>
> This is just a fixed (and small) overhead. Not actually double the<br>
> memory used by the entire grid.<br>
<br>
</div>agree.<br>
<div class="im"><br>
><br>
> Additional drawbacks:<br>
> - More complex lookups in the DC. Code that would otherwise just call<br>
> DC.get() would now need to also check L1DC. This would be scattered all<br>
> over the code-base - unless perhaps the main DC would implicitly also<br>
> check the contents of the L1DC (if one is available).<br>
<br>
</div>I don't think so. We should only query the L1DC just before performing<br>
the remote get. This way, only the DistributionInterceptor (and<br>
sub-classes) will keep a reference to L1DC to query, store, etc.<br></blockquote><div>That was my thought as well that the L1 interceptor would automatically put the L1 cached value in the context, which is simple for non Tx. Tx is a little muddier, but would be more clear when <a href="https://issues.jboss.org/browse/ISPN-1540">https://issues.jboss.org/browse/ISPN-1540</a> is added as well.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
possible advantages:<br>
<br>
* use it own lock manager<br>
* try reduce some network traffic by keep tracking the remote gets and<br>
if the key requested does not exist in the L1DC but another thread<br>
already made the remote get, it could skip a second remote get... this<br>
could be discussed later...<br></blockquote><div style>Yeah I already have a prototype for this where requests for gets on the same key would wait for the first to finish and would be done in a way that wouldn't also block writes. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
><br>
>><br>
>> Both?:<br>
>> 1. Additional configuration available<br>
>> a. Add maxEntires just like the normal data container (use data<br>
>> container size if not configured?)<br>
>> b. Eviction wakeup timer? We could just reuse the task cleanup<br>
>> frequency?<br>
>> c. Eviction strategy? I would think the default data container's<br>
>> would be sufficient.<br>
<br>
</div>for the beginning the current data container should work fine. But in<br>
the future, if we found that some parts can be optimized for the L1 uses<br>
cases, I think an optimized DC would be better.<br></blockquote><div style>My thought as well (Benefit #4) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">>><br>
>> I was wondering what you guys thought.<br>
>><br>
>> Thanks,<br>
>><br>
>> - Will<br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
</div>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
<div class="im">>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> --<br>
> Manik Surtani<br>
</div>> <a href="mailto:manik@jboss.org">manik@jboss.org</a> <mailto:<a href="mailto:manik@jboss.org">manik@jboss.org</a>><br>
> <a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a> <<a href="http://twitter.com/maniksurtani" target="_blank">http://twitter.com/maniksurtani</a>><br>
<div class="im">><br>
> Platform Architect, JBoss Data Grid<br>
> <a href="http://red.ht/data-grid" target="_blank">http://red.ht/data-grid</a><br>
><br>
><br>
><br>
</div><div class=""><div class="h5">> _______________________________________________<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>
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></div>