Create a RAMDirectoryProvider from an existing Lucene FSDirectory

Description

It would be nice to have the ability to use a Lucene RAM index which gets constucted from an existing Lucene file based indexed. For example in an JMS setup the master could create a file based Lucene index, share it out to the slaves which in turn use this file based index to populate a RAM index. This would give you the best of two worlds.

Not sure how hard it would be to implement this in an unclustered environment.

[*] read from FS at startup (optionally, should be configurabile)
[*] write back to FS at shutdown (optionally, should be configurabile)
[*] document the behaviour, especially warning about this case: some setups are doing local clustering: 2 instances sharing the directory. This obviously can't work, so they should avoid using this feature of writing back to FS.

Activity

Show:

Hardy FerentschikAugust 18, 2010 at 9:33 PM

I guess the whole issue is obsolete by now.

Emmanuel BernardJuly 24, 2010 at 8:46 AM

It's Hardy's baby. I would not mind closing this issue.

Sanne GrinoveroJuly 23, 2010 at 6:57 PM

well then I won't object if you take this out of the next version; my goal in starting this discussion was to find a reason to resolve this, as it's being postponed for years.

Emmanuel BernardJuly 23, 2010 at 6:21 PM

The core problem is that there is pretty much no identified use case for it

Sanne GrinoveroJuly 23, 2010 at 5:53 PM

that's true we could provide an helper explicitly meant for that, but I was wondering how to best implement this issue: it was created 3 years ago so I don't think we have a clear idea about it; working for RAM only seems limitating (and harder to impl to limit it to RAM only) - and otherwise it could also be used for the mentioned migration purposes. So it's more that I don't see shy we should limit it to RAM only, just do it generically and let people make the use they wish of it.

Rejected

Details

Assignee

Reporter

Components

Fix versions

Priority

Created November 13, 2007 at 12:26 AM
Updated September 11, 2011 at 6:21 PM
Resolved August 18, 2010 at 9:33 PM