Stefan Guggisberg wrote:
There are already working solutions for 2. and 3. So, as you wrote,
the right
way would be to refactor jackrabbits core to use an own storage. This
could even
be the current FileSystem, while this FileSystem lacks a proper locking
mechanism which probably could be added.
locking is imo not required in the jr FileSystem abstraction since jr
(or the
relevant subcomponent) *owns* the file system.
With locking I meant the ".lock" file jr creates on startup
(RepositoryImpl.acquireRepositoryLock). This file is created using java.io and
java.nio. If we could abstract this functionality into FileSystem there would be
no need for jr to access the filesystem directly to create a ".lock" file.
Would that work? The mentioned persistence managers could still use an
own
instance of the Jackrabbit FileSystem, while they might be better off
to use the
file system directly. I mean there is no sense in telling an XML
persistence
manager to use memory or database based FileSystem. You could as well
exchange
the persistence manager for a memory or database persistence manager.
i disagree. you might e.g. want to use the XMLPersistenceManager on a
DbPersistenceManager.
You probably mean "on a Db_FileSystem_", don't you? I still don't think it's a
good idea to do this, because you probably won't get a good performance using
this constellation. But if someone really needs it ...
there are imo 3 issues which make it currently impossible to run jr
exclusively in memory, i.e. without leaving any traces on the disk:
1. there's obviously an issue with the InMemPersistenceManager;
it uses a LocalFileSystem to persist blob's even with 'persistent=false'
feel free to open a jira issue for this.
Ok, I will open a ticket.
2. lucene doesn't use the jr FileSystem abstraction (there are valid
reasons
for this and they were explained on the mailing list).
you seem to have found a workaround for this. another option could
perhaps
be to disable SearchIIndex entirely.
But which component should do the queries? Or would you implement a QueryHandler
which simply traverse all nodes to get query results (performance?)? For me
using a lucene RAMDirectory is okay. I already added a parameter "persistent" to
SearchIndex which creates a PersistentIndex based on a RAMDirectory if set to
"true". I would be glad to provide a patch.
3. there's currently no InMemFileSystem available in jr. since you wrote
one
we'd be very interested if you'd consider contributing it ;-)
I implemented a very simple one based on a Map just to get something working.
But I would be happy to contribute it if there is demand.
with the above 3 issues resolved it should imo be possible to run
jackrabbit
entirely in memory.
If I do a search for java.io.File in jackrabbit core I found it to be used e.g.
in:
SessionImpl.createAccessManager()
RepositoryConfig.init()
RepositoryConfig.internalCreateWorkspaceConfig()
I think these occurrences have to be eleminated as well to make jackrabbit run
entirely in memory. Am I wrong?
Cheers,
Christoph
