[infinispan-dev] L1 Data Container

[William Burns]

On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero <sanne at infinispan.org>wrote:

> On 19 June 2013 16:44, cotton-ben <ben.cotton at alumni.rutgers.edu> wrote:
> >
> > />>    At the opposite site, I don't see how - as a user - I could
> optimally
> >>>    tune a separate container.
> >
> >> I agree that is more difficult to configure, this was one of my points
> as
> >> both a drawback and benefit.   It > sounds like in general you don't
> >> believe the benefits outweigh the drawbacks then./
> >
> > Hi William.  The benefits of your ambition to provide  L1 capability
> > enhancements -- for /certain/ user's completeness requirements--
> definitely
> > outweigh the drawbacks . This is a FACT.
>
> I have to disagree ;-) It certainly is a fact that he's very well
> intentioned to make enhancements, but I don't this strategy is proven
> the be superior; I'm actually convinced of the opposite.
>
> We simply cannot assume that the "real data" and the L1 stored entries
> will have the same level of hotness, it's actually very likely (since
> you like stats) that the entries stored in L1 are frequently accessed,
> to the opposite of other entries which - for as far as we know - could
> be large and dormant for years.
>
Actually this is only half true, we know that the values are hot on this
node specifically.  Other nodes could be requesting the "cold" data quite
frequently as well.  This could lead to L1 values pushing out distributed
data leaving it where nodes have L1 cached values for which the owner
doesn't even own.  And when the L1 cache value expires there will be no
more backup (not including passivation).  This is a very odd situation
though, since you can't do conditional operations then as well.

And even with separate containers this is possible to have the L1
discrepency, but actually having a lower lifespan would help remedy this
since every once in a while the "hot" value would have to retrieved again
from the owning node.

>
> Storing useless data in memory is going to force to evict entries from
> L1 which are hot by definition (as they wouldn't be in L1 otherwise -
> as you pointed out there likely is an expiry) is a strategy which
> actively strives towards a less efficient storage.
>
> Also L1 timeout can be disabled, making for a very nice self-tuning
> adaptive system.
>
The value cannot be disabled for the timeout.  Unless by disable you mean
to increase the timeout so high that it will never be hit?  Is that a
common use case?

>
> Sanne
>
> >
> > However, for the /typical/ user's completeness requirements, this FACT
> > probably won't be relevant.
> >
> >
> >
> > --
> > View this message in context:
> http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-L1-Data-Container-tp4027447p4027463.html
> > Sent from the Infinispan Developer List mailing list archive at
> Nabble.com.
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> 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/20130619/dba713a5/attachment.html