[ https://issues.apache.org/jira/browse/OAK-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14716778#comment-14716778 ]
Thomas Mueller commented on OAK-3148: ------------------------------------- Some remarks: I would avoid abbreviations in class names, so instead of DfsNodeIterator use DepthFirstNodeIterator(?) (first I thought it means DataFileStoreNodeIterator or something like that). I would avoid using "final" for local variables and parameters where possible. For fields, sure final makes sense. But otherwise, I think it just adds clutter. Specially in tests. commit() can fail and return a boolean. Maybe rename it to tryCommit? Similar to Java FileChannel.tryLock. Do you know how much the BloomFilter helps for your case, and how much memory it uses? > Online migration process for the binaries > ----------------------------------------- > > Key: OAK-3148 > URL: https://issues.apache.org/jira/browse/OAK-3148 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob, upgrade > Reporter: Tomek Rękawek > Priority: Minor > Fix For: 1.4 > > > For clients that want to migrate their blob stores, let's add a new feature > that allows copy them in the background. > AC: > # SplitBlobStore > ## Administrator can configure Oak to use the {{SplitBlobStore}} that > references the source (old) and the destination (new) blob store. > ## Data stores can be used as well via the {{DataStoreBlobStore}}. > ## On the read operation, if the requested blob exists on the new store, > SplitBlobStore will return it. > ## Otherwise, SplitBlobStore will try to read the blob from the old store. > ## All write requests will be directed to the new blob store. > # Copy process > ## Administrator can start, stop and resume the copy process using JMX > command. > ## Administrator can see the progress in JMX and logs > ## The process will read the {{SplitBlobStore}} configuration and copy the > binaries from source to destination > ## Once a binary is moved, its reference in the {{NodeStore}} is updated and > commited. > ## Only the head revision has to be updated. > The idea is that after all binaries are copied, the old revisions will be > gradually removed by the compaction mechanisms and then binaries will be > removed from the source store by the blob garbage collector. Future > improvements are possible, eg. to invoke the compaction and GC manually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)