8:46 a.m.
On 27-10-2016 14:20, William Burns wrote:
On Thu, Oct 27, 2016 at 4:56 AM Pedro Ruivo <pedro(a)infinispan.org
<mailto:pedro@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev