On 27-10-2016 14:20, William Burns wrote:
>
>
> On Thu, Oct 27, 2016 at 4:56 AM Pedro Ruivo <pe...@infinispan.org
> <mailto:pe...@infinispan.org>> wrote:
>
>
>
> On 26-10-2016 23:06, William Burns wrote:
> > I have been working on adding in off heap support for a given
> cache. I
> > wanted to check in and let you all know what I was thinking for the
> > configuration and changes that would come about with it.
> >
> > TLDR;
> > New config under data container to enable off heap, StoreAsBinary
> > removed, Equivalence removed
> >
> > First I was planning on adding new sub elements of data container.
> > These would be instance, binary and off-heap. Only of the three could
> > be picked as they are mutually exclusive. Instance is as we
> operate now
> > where we store the instance of the object passed to us. Binary is
> > essentially what we have now that is called storeAsBinary with
> both keys
> > and values converted. Lastly off-heap would store the entry as a
> byte[]
> > store completely in native memory.
>
> I prefer 'object' instead of 'instance'.
>
>
> Sounds fine with me.
>
>
>
> Are you also planning to remove the expiration and/or eviction
> configuration elements and set them in the data-container sub elements?
>
>
> I wasn't planning on touching those. But now that you mention it,
> eviction only makes sense in the data container, where as expiration is
> container and cache store. And taking this further storeAsBinary is
> both as well, only off-heap is container only. I wonder if instead we
> should have a separate storage element at the same level as
> data-container. I can see it either way.
Let me know if this makes sense:
<expiration> //no changes here
<memory evictionStrategy=... evictionPolicy=...>
//one of the following
<on-heap max-entries=.../>
<on-heap-binary max-size=.../>
<off-heap ...max-size? and off-heap config.../>
</memory>
<persistence> //no changes here
wdyt?
>
>
>
>
> >
> > Example:
> >
> > <data-container>
> > <off-heap/>
> > </data-container>
> >
> > The reason it is a subelement instead of a property is because
> off-heap
> > will most likely require some additional configuration to tell how
> many
> > entries to store in the a bucket (think non resizing HashMap).
> >
> > With these changes storeAsBinary becomes redundant, so I was
> planning on
> > removing this configuration completely. I would rather remove since
> > this is 9.0 and not deprecate. As far as I know nobody really used it
> > before.
> >
> > Also another side effect is I was removing all of the Equivalence
> > classes. I am not sure if I can plainly remove them since they have
> > lived in commons for quite a while, but it would be best if I could,
> > although I am fine deprecating. In its place the instance setting for
> > data-container will always wrap byte[] to satisfy equals and hashCode
> > methods.
> >
> > Any feedback would be appreciated.
> >
> > Thanks,
> > - Will
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
