<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 1:27 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: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=""><div class="h5">On 19 June 2013 17:17, William Burns <<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
> wrote:<br>
>><br>
>> On 19 June 2013 16:44, cotton-ben <<a href="mailto:ben.cotton@alumni.rutgers.edu">ben.cotton@alumni.rutgers.edu</a>> wrote:<br>
>> ><br>
>> > />> At the opposite site, I don't see how - as a user - I could<br>
>> > optimally<br>
>> >>> tune a separate container.<br>
>> ><br>
>> >> I agree that is more difficult to configure, this was one of my points<br>
>> >> as<br>
>> >> both a drawback and benefit. It > sounds like in general you don't<br>
>> >> believe the benefits outweigh the drawbacks then./<br>
>> ><br>
>> > Hi William. The benefits of your ambition to provide L1 capability<br>
>> > enhancements -- for /certain/ user's completeness requirements--<br>
>> > definitely<br>
>> > outweigh the drawbacks . This is a FACT.<br>
>><br>
>> I have to disagree ;-) It certainly is a fact that he's very well<br>
>> intentioned to make enhancements, but I don't this strategy is proven<br>
>> the be superior; I'm actually convinced of the opposite.<br>
>><br>
>> We simply cannot assume that the "real data" and the L1 stored entries<br>
>> will have the same level of hotness, it's actually very likely (since<br>
>> you like stats) that the entries stored in L1 are frequently accessed,<br>
>> to the opposite of other entries which - for as far as we know - could<br>
>> be large and dormant for years.<br>
><br>
> Actually this is only half true, we know that the values are hot on this<br>
> node specifically. Other nodes could be requesting the "cold" data quite<br>
> frequently as well.<br>
<br>
</div></div>I see where you're coming from, but my point is the opposite: if other<br>
nodes would be requesting this data quite frequently, it woudln't be<br>
considered "cold": by using a single data container the eviction<br>
strategy automatically takes this into account as well. A hit is a hit<br>
in all senses.<br></blockquote><div style>Yeah but a hit in the L1 doesn't constitute a hit on the owner is what I was getting at.</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>
> This could lead to L1 values pushing out distributed<br>
> data leaving it where nodes have L1 cached values for which the owner<br>
> doesn't even own.<br>
<br>
</div>That's just another excellent reason to keep a unified datacontainer:<br>
if a different node uses the value frequently, allow it to be cached<br>
for read operations, even if the primary owner is passivating it.<br>
Write operations are inherently safe as they have to go through the<br>
owner and trigger entry activation as needed.<br></blockquote><div style>I think this may be a disconnect, I was thinking if they didn't have passivation. I agree with passivation, there is really no reason to worry. Although I still think you wouldn't want to passivate a L1 cache entry as it would most likely be faster to hit the owning node and actually would cause a hit on the owning nodes.</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>
> And when the L1 cache value expires there will be no more<br>
> backup (not including passivation). This is a very odd situation though,<br>
> since you can't do conditional operations then as well.<br>
<br>
</div>Conditional operations would hit the owner, and by doing so trigger<br>
loading. Not too odd, as it's the design today.<br></blockquote><div style>Same as previous - issue with no passivation.<br></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>
> And even with separate containers this is possible to have the L1<br>
> discrepency, but actually having a lower lifespan would help remedy this<br>
> since every once in a while the "hot" value would have to retrieved again<br>
> from the owning node.<br>
<br>
</div>Should be unnecessary, consistency is guaranteed no matter what<br>
timeouts of lifespans are set.<br></blockquote><div>Same as previous - issue with no passivation. </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>
>> Storing useless data in memory is going to force to evict entries from<br>
>> L1 which are hot by definition (as they wouldn't be in L1 otherwise -<br>
>> as you pointed out there likely is an expiry) is a strategy which<br>
>> actively strives towards a less efficient storage.<br>
>><br>
>> Also L1 timeout can be disabled, making for a very nice self-tuning<br>
>> adaptive system.<br>
><br>
> The value cannot be disabled for the timeout. Unless by disable you mean to<br>
> increase the timeout so high that it will never be hit? Is that a common<br>
> use case?<br>
<br>
</div>Sure why not, any read-mostly system would benefit from it: think of<br>
video streaming services, online stores (amazon like or app stores),<br>
news papers. Basically, most systems on which I'd suggest to enable<br>
L1.<br>
BTW I think L1's lifespan accepts a -1 as well, which should result in<br>
immortal cache entries.<br></blockquote><div style>Checking the L1ConfigurationBuilder it throws an exception if there is a value < 1.</div><div style><br></div><div style><div> public void validate() {</div><div> if (enabled) {</div>
<div> ...</div><div> if (lifespan < 1)</div><div> throw new ConfigurationException("Using a L1 lifespan of 0 or a negative value is meaningless");</div><div><br></div><div> }</div>
<div> ...</div><div> }</div></div><div style><br></div><div style> I am wondering if this should be changed then to allow a -1 since it is a common use case to allow for never expiring L1 entries.</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">
<span class=""><font color="#888888"><br>
Sanne<br>
</font></span><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>
</div></div></blockquote></div><br></div></div>