[infinispan-issues] [JBoss JIRA] Commented: (ISPN-78) Large object support

[Olaf Bergner (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597766#comment-12597766 ] 

Olaf Bergner commented on ISPN-78:
----------------------------------

Hi Gabriel,

it is my understanding that Reed-Solomon codes aide in detecting and correcting data corruption. In our scenario this equates to repairing chunks that have somehow been corrupted. I have thought about later implementing some means of doing so myself, so thanks for the hint.

What I fail to see, though, is how this would help to address the problem of availability in the face of node failures. If two nodes storing the same chunk are down that chunk and thus the large object it belongs to are not available. Or would it be possible using RS codes to reconstruct a missing chunk from the information contained in the other chunks?

> Large object support
> --------------------
>
>                 Key: ISPN-78
>                 URL: https://issues.jboss.org/browse/ISPN-78
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core API
>            Reporter: Manik Surtani
>            Assignee: Olaf Bergner
>             Fix For: 5.1.0.BETA1, 5.1.0.Final
>
>
> if each VM is allocated a 2GB heap and you have a 100 nodes in a grid with 1 redundant copy for each key, you have a theoretical addressable heap of 100GB.  But you are limited by (half) the heap of a single VM per entry, since entries are stored whole.
> E.g., cache.put(k, my2GBObject) will fail since you need at least 2GB for the object + another 2GB for its serialized form.
> This gets worse when you try cache.put(k, my10GBObject).  This *should* be possible if we have a theoretical 100GB heap.
> Potential solutions here are to fragment large objects, and store each fragment under separate keys.  Another approach would be to directly stream objects to disk. etc.  Needs thought and design, possibly a separate API to prevent 'pollution" of the more simplistic API.  (JumboCache?)
> Re: fragmenting, issues to overcome:
> How many chunks to fragment into?  Max size of each key could be configured, but how do we determine the size of an Object?  VM instrumentation?  Or perhaps the JumboCache only stores byte[]'s?  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira