jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-56) File system abstraction
Date Tue, 10 Apr 2012 15:37:18 GMT

    [ https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250750#comment-13250750

Thomas Mueller commented on OAK-56:

> I guess this should be better approached from the top instead of from the bottom.

For some things are easier if you use a service provider interface. Java itself uses the service
provider interface quite a lot. We had a file system abstraction in Jackrabbit 2.x, unfortunately
we didn't use it in many cases. Please note Java 7 has a file system abstraction as well,
and the proposed API is very similar to Java 7. Once Java 7 is the minimum requirement we
can remove our own abstraction and use the Java features. But I guess we will have to support
Java 6 for quite some time still.

> Do we want to implement a MK with features like the ones you describe?

Yes. We have to, if we want to replace CRX 2.x without losing features. Of course we can implement
the whole MK stack again in CRX, *with* the abstraction, but I think that's kind of pointless
(specially for the data store). Or we can do it as we did in CRX, that is, implement the features
without using an abstraction. But I would like to avoid that, because this resulted in a non-optimal
and very inflexible solution.

> Do we want to implement a MK with features like the ones you describe? 
> If yes, should that be the default implementation included in oak-mk or a separate component?

Yes, that's what I propose.

> File system abstraction
> -----------------------
>                 Key: OAK-56
>                 URL: https://issues.apache.org/jira/browse/OAK-56
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, mk
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>            Priority: Minor
> A file system abstraction allows to add new features (cross cutting concerns) in a modular
way, for example:
> - detection and special behavior of out-of-disk space situation
> - profiling and statistics over JMX
> - re-try on file system problems
> - encryption
> - file system monitoring
> - replication / real-time backup on the file system level (for clustering)
> - caching (improved performance for CRX)
> - allows to easily switch to faster file system APIs (FileChannel, memory mapped files)
> - debugging (for example, logging all file system operations)
> - allows to implement s3 / hadoop / mongodb / ... file systems - not only by us but from
3th party, possibly the end user
> - zip file system (for example to support read-only, compressed repositories)
> - testing: simulating out of disk space and out of memory (ensure the repository doesn't
corrupt in this case)
> - testing: simulate very large files (using an in-memory file system)
> - splitting very large files in 2 gb blocks (FAT and other file systems that don't support
large files)
> - data compression (if needed)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message