[ https://jira.jboss.org/jira/browse/ISPN-78?page=com.atlassian.jira.plugin... ] Galder Zamarreno commented on ISPN-78: -------------------------------------- Some interested in the public user forums: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239685#... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/ISPN-78?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-78: ------------------------------ Fix Version/s: 4.1.0.CR1 (was: 4.1.0.BETA1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.syst... ] Manik Surtani updated ISPN-78: ------------------------------ Fix Version/s: 5.0.0.BETA1 5.0.0.Final (was: 4.1.0.Final) (was: 4.1.0.CR1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Thomas Fuller commented on ISPN-78: ----------------------------------- Regarding "[H]ow do we determine the size of an Object? VM instrumentation?" This is a good question because I've been thinking about exactly how to do this, but for another purpose -- basically determining what the memory mapping of the grid looks like as a whole, so I'd be interested in getting involved in this discussion. Regarding "Potential solutions here are to fragment large objects, and store each fragment under separate keys." IMO this sounds messy and I can see this resulting in some strange bugs. "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?)" IMO this seems like a much cleaner approach. Tom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Thomas Fuller commented on ISPN-78: ----------------------------------- Would it be possible to make this a configuration option? For some applications it may make more sense to just save the object -- for example, if the object is not expected to be accessed much. T -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Olaf Bergner edited comment on ISPN-78 at 3/29/11 7:46 PM: ----------------------------------------------------------- Wouldn't a non streaming API somehow defeat this feature's sole purpose? It is my understanding that it is driven by the desire to store objects the size of which exceeds that of every single JVM in the cluster, correct? If that is indeed the case, it would be *impossible* to store such an object without first fragmenting it into pieces each of which fits into a single node's heap. So we need a streaming API to read a large object from some place - think file - outside the current JVM's address space in order not to blow up that JVM's heap. It is out of the question that this approach considerably complicates matters, but I don't see a way around it. was (Author: O.Bergner): Wouldn't a non streaming API somehow defeat this feature's sole purpose? It is my understanding that it is driven by the desire to store objects the size of which exceeds that of every single JVM in the cluster, correct? If that is indeed the case, it would be *impossible* to store such an object without first fragmenting into it pieces each of which fits into a single node's heap. So we need a streaming API to read a large object from some place - think file - outside the current JVM's address space in order not to blow up that JVM's heap. It is out of the question that this approach considerably complicates matters, but I don't see a way around it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Olaf Bergner commented on ISPN-78: ---------------------------------- I started an - as of now rather exploratory - implementation at https://github.com/obergner/infinispan/tree/t_ispn78. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Olaf Bergner edited comment on ISPN-78 at 3/29/11 8:01 PM: ----------------------------------------------------------- Wouldn't a non streaming API somehow defeat this feature's sole purpose? It is my understanding that it is driven by the desire to store objects the size of which exceeds that of every single JVM in the cluster, correct? If that is indeed the case, it would be *impossible* to store such an object without first fragmenting it into pieces each of which fits into a single node's heap. So we need a streaming API to read a large object from some place - think file - outside the current JVM's address space in order not to blow up that JVM's heap. It is out of the question that this approach considerably complicates matters, but I don't see a way around it. Ah, I see. Stupid me. Streaming to disk means writing a large object directly through to the cache store, without actually caching it in memory. Might make sense in some cases, though it could be argued if in this case Infinispan would really act as a "cache". We would still need a streaming API, though. Anyway, IMHO we should first concentrate on implementing the "fragmentation approach" and then check back whether streaming to disk might make sense. One step at a time. was (Author: O.Bergner): Wouldn't a non streaming API somehow defeat this feature's sole purpose? It is my understanding that it is driven by the desire to store objects the size of which exceeds that of every single JVM in the cluster, correct? If that is indeed the case, it would be *impossible* to store such an object without first fragmenting it into pieces each of which fits into a single node's heap. So we need a streaming API to read a large object from some place - think file - outside the current JVM's address space in order not to blow up that JVM's heap. It is out of the question that this approach considerably complicates matters, but I don't see a way around it. Ah, I see. Stupid me. Streaming to disk means writing a large object through directly to the cache store, without actually caching it in memory. Might make sense in some cases, though it could be argued if in this case Infinispan would really act as a "cache". We would still need a streaming API, though. Anyway, IMHO we should first concentrate on implementing the "fragmentation approach" and then check back whether streaming to disk might make sense. One step at a time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Trustin Lee commented on ISPN-78: --------------------------------- 1) Is it a good idea to put the chunks into {{Cache}}? What about storing them in a separate store specialized for large objects? For example, a user might want to store ordinary entries in heap while large objects in disk. Maybe a user could specify two store implementations when creating a {{Cache}} - one for non-large objects and the other for large objects. 2) What about an interface like this to put a large object? {code} public interface LargeObjectWriter { void write(byte[] data, int offset, int length) throws IOException; void transferFrom(InputStream in) throws IOException; void cancel(); void finish(); } public interface Cache { ... LargeObjectWriter writeToKey(K key); } Cache c = ...; LargeObjectWriter writer = c.writeToKey("largeObject"); boolean success = false; try { writer.transferFrom(new FileInputStream("largeObject.iso"); success = true; } finally { if (success) { writer.finish(); // Upload is final } else { writer.cancel(); // Discard the stream - writeToKey has no effect on the cache i.e. any chunks and entries written so far are removed from the cache. } } {code} 3) Because a user can upload the large object later as long as the current transaction is valid, the method name '{{writeToKey}}' doesn't sound right - the method itself does not write anything. So, I think it might be a good idea to give a better name to {{writeToKey()}}. Maybe {{Cache.newLargeObject(K key)}}? 4) A user might want to access the list of chunks and access them individually (e.g. range access). Therefore, {{Cache.get(K key)}} should not throw CacheException but return a {{LargeObjectMetadata}} and the {{LargeObjectMetaData}} should provide a way to retrieve the list of chunks. For example: {code} interface LargeObjectMetadata { LargeObjectChunkRange[] getChunkKeys(int offset, int length); String[] getChunkKeys(); } interface LargeObjectChunkRange { String chunkKey; int offset; // first chunk might have non-zero offset int length; // last chunk might have a smaller value than the actual length } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Olaf Bergner commented on ISPN-78: ---------------------------------- Hi Trustin, 1) Well, chunking is the solution MongoDB found for their GridFS - http://www.mongodb.org/display/DOCS/GridFS+Specification - and so far it seems to serve them well. At least I know that people are successfully using GridFS. That being said it might indeed be desirable to additionally support an alternative where large objects are written through the cache to disk. I personally would opt to first implement the current solution based on chunking and see how it goes. Later, if the need arises, we should be able to transparently support write-through caches, too. 2) Right now the interface is {code} public interface StreamingHandler<K> { void writeToKey(K key, InputStream largeObject); OutputStream writeToKey(K key); InputStream readFromKey(K key); boolean removeKey(K key); StreamingHandler<K> withFlags(Flag... flags); } {code} i.e. I support {{transferFrom(InputStream)}} via {{writeToKey(K, InputStream}}} and {{write(byte)}} via {{OutputStream writeToKey(K)}}. Using the latter a client will have to call {{close()}} on the {{OutputStream}} returned to complete the write. It seems to me that this very similar to your {{LargeObjectWriter}}. 3) Yes, method naming could definitely be improved and {{newLargeObject(K key)}} seems to make sense. I'm not so sure, though, that it would still be appropriate when *overwriting* an existing key. Maybe simply {{largeObject(K key)}}? 4) I don't think a user should know about the chunks a large object is partitioned into. After all, it's just an implementation detail and the exact structure of the partitioning scheme chosen by INFINISPAN is likely immaterial to the domain at hand. One exception might be when the user chooses the configurable chunk size according to not technical but functional reasons, i.e. he knows that a single record within a large file will *always* be 256k in size. But then he may use the {{InputStream}} returned from {{readKey(K key)}} to read a large object in chunks of arbitrary size. As a general approach I would like to first get the interface and - by extension - implementation details directly affecting the interface right. How to best implement that interface is a question we may answer later. The more I think about it, the less likely it seems to me that a user will *ever* want to mix "regular" and large objects within a single cache. At least most applications I know of wouldn't want to do so. Plus I imagine that it might prove difficult to tune a cache containing regular as well as large objects. Maybe we should restrict storage of large objects to dedicated caches? This would have the added bonus of being able to define appropriate default settings for large object caches. Any thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Gabriel Ciuloaica commented on ISPN-78: --------------------------------------- Hi Olaf, Sure, the all idea is that when you use a RS algorithm you generates the chunks such that each chunk has some more data added to it. In order to reconstruct the original object you need just a subset of those chunks. There is an algorithm to determine how to split the object in chunks based on availability requirement. You'll never need all of them. Let me try to find a good example. I remember seen something some time ago... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Gabriel Ciuloaica commented on ISPN-78: --------------------------------------- Thanks Olaf. It was just a suggestion. I think the approach to start simple and than enrich the functionality is the best approach. In the meantime I will try to spike an implementation in java for RS algorithm. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-78: ------------------------------ Fix Version/s: 5.2.0.FINAL (was: 5.1.0.BETA1) (was: 5.1.0.FINAL) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Ales Justin commented on ISPN-78: --------------------------------- @Manik: with Marko' fixes to GFS, this should, imo, just be an API facade on top of existing GFS impl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-78?page=com.atlassian.jira.plugin.sy... ] Mircea Markus updated ISPN-78: ------------------------------ Fix Version/s: 5.2.0.Alpha4 (was: 5.2.0.Alpha3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira