[infinispan-dev] Data Container configuration changes

Pedro Ruivo pedro at infinispan.org
Thu Oct 27 09:46:40 EDT 2016



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


More information about the infinispan-dev mailing list