bq. We switched to ByteBuffersDirectory with 7.5, but
I actually didn't see much performance improvements or savings in memory.
Once the indexes are built I don't think there will be much of a
difference. The core problem with RAMDirectory was related to
synchronizations during me
ult-level cache though, if you have a
relatively large amount of repeated queries.
With regards to RAMDirectory (and its successor the
ByteBuffersDirectory), it works well enough for our setup: we run an
in-memory copy of our regular sql database in an elastic search like
setup to support very fast r
Hi Joe,
Elasticsearch used to have an option to run with RAMDirectory but it
was removed long ago:
https://github.com/elastic/elasticsearch/pull/8536.
The recommended approach is to use MMapDirectory and to give
sufficient memory to the filesystem cache so that the most important
data-structures
Greetings,
Has anyone looked into using Redis or some other in-memory cache with Lucene?
It seems that ElasticSearch may do this. Are there advantages to doing this
versus, say, the RAMDirectory class?
Thanks in advance,
J
Thanks Dawid, glad I asked!
Am Dienstag, den 25.09.2018, 10:46 +0200 schrieb Dawid Weiss:
> Use MMapDirectory on a temporary location, Matthias. If you really
> need in-memory indexes, a new Directory implementation is coming
> (RAMDirectory will be deprecated, then removed), but the d
Use MMapDirectory on a temporary location, Matthias. If you really
need in-memory indexes, a new Directory implementation is coming
(RAMDirectory will be deprecated, then removed), but the difference
compared to MMapDirectory is typically not worth the hassle. See this
issue for more discussion
Hi,
Lucene provides different storage options for in-memory indexes. I
found three structures that would qualify for the task:
* RamDirectory (which I currently use for prototyping, but wonder if it
is the ideal choice for my task)
* MemoryIndex, which claims to have better performance and
ave a fun issue I'm dealing with at the junction of lucene and spark.
> >
> > I have an RDD[(key, iterator1, iterator2)]
> >
> > I run a mapPartitions on the RDD, and for each partition, I create a
> > ramDirectory, I index all of the elements in interator1, and th
h partition, I create a
> ramDirectory, I index all of the elements in interator1, and then I search
> the index for each element in iterator2. The issue that I am having is all
> of my searches on the ramDirectory fail with an "EOF exception" Here is
Hey All,
I have a fun issue I'm dealing with at the junction of lucene and spark.
I have an RDD[(key, iterator1, iterator2)]
I run a mapPartitions on the RDD, and for each partition, I create a
ramDirectory, I index all of the elements in interator1, and then I search
the index for each el
Thanks for the quick reply Uwe!
I opened https://issues.apache.org/jira/browse/LUCENE-7366 for this.
-Rob
On Thu, Jun 30, 2016 at 12:06 PM, Uwe Schindler wrote:
> Hi,
>
> I looked at the code: The FSDirectory passed to RAMDirectory could be
> changed to Directory easily. The addi
Hi,
I looked at the code: The FSDirectory passed to RAMDirectory could be changed
to Directory easily. The additional check for "not is a directory inode" is in
my opinion lo longer needed, because listFiles should only return files.
Can you open an issue about to change the FSDirect
Hi all,
For increasing the speed of some of my application tests, I want to
re-use/copy a pre-populated RAMDirectory over and over.
I'm on Lucene 6.0.1
It seems an RAMDirectory can be a copy of a FSDirectory, but not of another
RAMDirectory. Also RAMDirectory is not Clonable.
What would b
Hi Folks,
Is it recommended to do singleton instantiation of RAMDirectory throw
spring bean or is it okay to create new instance on every method call ?
Thanks in advance.
--
Regards,
Prateek Singhal
Software Development Engineer @ Amazon.com
"Believe in yourself and you can do unbelie
On Wed, 2014-05-07 at 15:46 +0200, Cheng wrote:
> I have an index of multiple gigabytes which serves 5-10 threads and needs
> refreshing very often. I wonder if RAMDirectory is the good candidate for
> this purpose. If not, what kind of directory is better?
RAMDirectory will probably
On May 7, 2014, at 6:46 AM, Cheng wrote:
>
> I have an index of multiple gigabytes which serves 5-10 threads and needs
> refreshing very often. I wonder if RAMDirectory is the good candidate for
> this purpose. If not, what kind of directory is better?
We found that loading a
Hi,
I have an index of multiple gigabytes which serves 5-10 threads and needs
refreshing very often. I wonder if RAMDirectory is the good candidate for
this purpose. If not, what kind of directory is better?
Thanks,
Cheng
Yeah, already done that (after some experimenting):
static void serializeRAMDirectory( RAMDirectory dir, output ){
if( null == dir ) return
output?.withObjectOutputStream{ out ->
out.writeLong dir.sizeInBytes()
out.writeInt dir.fileMap.size()
dir.fileMap.each{ Str
In Lucene 3.x the RAMDirectory was Serializable.
>
> In 4.x not any more...
>
> what's the best/most performant/easies way to serialize the RAMDir in 4.6.0?
>
> TIA
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Serializin
Hi all,
In Lucene 3.x the RAMDirectory was Serializable.
In 4.x not any more...
what's the best/most performant/easies way to serialize the RAMDir in 4.6.0?
TIA
--
View this message in context:
http://lucene.472066.n3.nabble.com/Serializing-RAMDirectory-in-4-6-0-tp4111999.html
Sent
On Tue, May 21, 2013 at 3:12 PM, Konstantyn Smirnov wrote:
> I want to refresh the topic a bit.
>
> Using the Lucene 4.3.0, I could'n find a method like expungeDeletes() in
> the
> IW anymore.
http://lucene.apache.org/core/4_3_0/core/org/apache/lucene/index/IndexWriter.html#forceMergeDeletes()
plish that was writer.forceMerge( 1 ), but it includes
the optimization.
Are there any other "cheaper" ways to do that?
TIA
--
View this message in context:
http://lucene.472066.n3.nabble.com/RAMDirectory-and-expungeDeletes-optimize-tp3994350p4064890.html
Sent from the Lucene - Jav
RAMDirectory generally has high GC cost for a large index because it always
allocates byte[1024] as its "pages". See eg
http://blog.mikemccandless.com/2012/07/lucene-index-in-ram-with-azuls-zing-jvm.html
But, you are hitting lots of new gen garbage, which is different.
ExactPhraseSco
attaching the second screen shot of live recorded objects .
thanks again
Alon
On Wed, Jan 9, 2013 at 7:34 PM, Alon Muchnick wrote:
> hi ,
> after upgrading to Lucune 3.6.2 i noticed there is an extensive minor
> garbage collection operations. once or twice a second , and the amount of
> memor
hi ,
after upgrading to Lucune 3.6.2 i noticed there is an extensive minor
garbage collection operations. once or twice a second , and the amount of
memory being freed is about 600 MB each time for a load of 60 searches per
second :
2013-01-09T18:57:24.350+0200: 174200.121: [GC [PSYoungGen:
630064
Thanks for bringing closure Alon.
In 3.0.3 each thread had a private terms dict cache, so that explains
the high per-thread RAM usage. This was fixed at some 3.x release ...
so we won't be fixing 3.0.3 at this point.
Mike McCandless
http://blog.mikemccandless.com
On Fri, Jan 4, 2013 at 8:29 AM
Robert you were absolutely right , we had a problem with our deployment
script and the Lucune Jars were not updated to 3.6.2 , they remained 3.0.3
...
after deploying the application again with the updated jars , the memory
leak is gone !
(although i do see a lot more gc activity on the YoungGen
On Thu, Jan 3, 2013 at 12:16 PM, Alon Muchnick wrote:
> value org.apache.lucene.index.TermInfosReader$ThreadResources --->
>
> termInfoCache |org.apache.lucene.util.cache.SimpleLRUCache
> termEnum |org.apache.lucene.index.SegmentTermEnum
>
You aren't using lucene 3.6.2 if you have th
On Thu, Jan 3, 2013 at 12:16 PM, Alon Muchnick wrote:
> hi Mike ,
>
> at the peak there are 500 live threads going through Lucune (not all of
> them at the same time , tomcat thread pool uses round robin ) ,regarding
> the Directory impl we are using RAMDirectory.
> the obje
hi Mike ,
at the peak there are 500 live threads going through Lucune (not all of
them at the same time , tomcat thread pool uses round robin ) ,regarding
the Directory impl we are using RAMDirectory.
the object that takes most of the heap is the "hardRefs" WeakHashMap class
mem
or replying .
>
> i am not sure when the doClose() method of the SegementReader will be
> called ,
> but i think you are correct regarding the SegmentReader still being live ,
> we have an singleton object with a hash map of several RamDirectory indexes
> and their IndexReader, In
hi MIke,
thank you very much for replying .
i am not sure when the doClose() method of the SegementReader will be
called ,
but i think you are correct regarding the SegmentReader still being live ,
we have an singleton object with a hash map of several RamDirectory indexes
and their IndexReader
application on tomcat 7, unfortunately we seem to
> encounter a memory link in Lucune's CloseableThreadLocal class , any help
> with solving the below issue would be much appreciated.
>
>
> we are using RAMDirectory for our Indexes , while testing the application
> on tomca
, unfortunately we seem to
encounter a memory link in Lucune's CloseableThreadLocal class , any help
with solving the below issue would be much appreciated.
we are using RAMDirectory for our Indexes , while testing the application
on tomcat 7 we noticed that there is a memory leak in our application ,
we are using RAMDirectory for our Indexes , while testing the application
on tomcat 7 we noticed that there is a memory leak in our application ,
after taking a heap dump we can see the memory leak is in the:
Type |Name|
Sent: Wednesday, July 11, 2012 10:07 AM
To: java-user@lucene.apache.org
Subject: Re: RAMDirectory and expungeDeletes()/optimize()
What I meant was your original email says "My code looks like",
followed by blank lines, and then "Doesn't it conflict with the
JavaDoc saying:", follow
What I meant was your original email says "My code looks like",
followed by blank lines, and then "Doesn't it conflict with the
JavaDoc saying:", followed by blank lines. Ie we can't see your code.
However, when I look at your email here at
http://lucene.472066.
JavaDoc comes from here
http://lucene.apache.org/core/3_6_0/api/all/org/apache/lucene/index/IndexWriter.html#expungeDeletes()
other blanks are here because it's groovy :) Or what did you mean exactly?
--
View this message in context:
http://lucene.472066.n3.nabble.com/RAMDirector
> to 100k) using the RAMDirectory.
> Then I need to send the segment over the network to be merged with the
> existing index other there.
>
> The segment need to be as "slim" as possible, e.g. without any pending
> deleted documents.
>
> My code looks like
>
>
Hi all
in my app (Lucene 3.5.0 powered) I index the documents (not too many, say up
to 100k) using the RAMDirectory.
Then I need to send the segment over the network to be merged with the
existing index other there.
The segment need to be as "slim" as possible, e.g. without any pendi
Can you explain how you are using Lucene?
>>
>> You may also want to try the CachingRAMDirectory patch on
>> https://issues.apache.org/jira/browse/LUCENE-4123
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Sat, Jun 16, 2012 at 7:18 AM, Cheng
wrote:
> > After a number of test, the performance of MMapDirectory is not even
> close
> > to that of RAMDirectory, in terms of speed.
> >
> > My application w/ the former can only deal with 10 tasks per round while
> it
> > could handle over 90 w/ RAMDirecto
actions. I guess since MMapDir
needs to synchronize to a local drive that causes it to be slower.
The code is attached:
public class YYTLucene {
private static Logger logger = Logger.getLogger(YYTLuceneImpl.class);
private static FSDirectory indexDir;
private static RAMDirectory ramDir;
// private
http://blog.mikemccandless.com
On Sat, Jun 16, 2012 at 7:18 AM, Cheng wrote:
> After a number of test, the performance of MMapDirectory is not even close
> to that of RAMDirectory, in terms of speed.
>
> My application w/ the former can only deal with 10 tasks per round while it
> could handle ove
After a number of test, the performance of MMapDirectory is not even close
to that of RAMDirectory, in terms of speed.
My application w/ the former can only deal with 10 tasks per round while it
could handle over 90 w/ RAMDirectory.
I use the application in Linux.
What can be the reasons
Ramdirectory is no longer an interesting technique for this. It makes
garbage collection do a lot of work. With memory-mapped directory the
data is cached by the OS instead of Java, and OS is very good at this.
TieredMergePolicy is much smarter about time spent merging segments.
Lucene In Action
cheng2...@gmail.com]
> Sent: Monday, June 04, 2012 6:10 PM
> To: java-user@lucene.apache.org
> Subject: Re: RAMDirectory unexpectedly slows
>
> Can I control the size of ram given to either MMapDirectory or
> ByteBufferDirectory?
>
> On Mon, Jun 4, 2012 at 11:42 PM, U
t; cache.
> >
> > 1.
> >
> https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/apache/lucene/store/bytebuffer/ByteBufferDirectory.java
> >
> > On Mon, Jun 4, 2012 at 10:55 AM, Cheng wrote:
> > > My indexes are 500MB+. So it seems like th
> 1.
> https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/apache/lucene/store/bytebuffer/ByteBufferDirectory.java
>
> On Mon, Jun 4, 2012 at 10:55 AM, Cheng wrote:
> > My indexes are 500MB+. So it seems like that RAMDirectory is not good for
> > t
n/java/org/apache/lucene/store/bytebuffer/ByteBufferDirectory.java
>>
>> On Mon, Jun 4, 2012 at 10:55 AM, Cheng wrote:
>> > My indexes are 500MB+. So it seems like that RAMDirectory is not good for
>> > that big a size.
>> >
>> > My challenge, on
ill be cached in RAM regardless in the OS system IO
> cache.
>
> 1.
> https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/apache/lucene/store/bytebuffer/ByteBufferDirectory.java
>
> On Mon, Jun 4, 2012 at 10:55 AM, Cheng wrote:
> > My indexes are 500MB
/apache/lucene/store/bytebuffer/ByteBufferDirectory.java
On Mon, Jun 4, 2012 at 10:55 AM, Cheng wrote:
> My indexes are 500MB+. So it seems like that RAMDirectory is not good for
> that big a size.
>
> My challenge, on the other side, is that I need to update the indexes very
> fre
My indexes are 500MB+. So it seems like that RAMDirectory is not good for
that big a size.
My challenge, on the other side, is that I need to update the indexes very
frequently. So, do you think MMapDirectory is the solution?
Thanks.
On Mon, Jun 4, 2012 at 10:30 PM, Jack Krupansky wrote
From the javadoc for RAMDirectory:
"Warning: This class is not intended to work with huge indexes. Everything
beyond several hundred megabytes will waste resources (GC cycles), because
it uses an internal buffer size of 1024 bytes, producing millions of
byte[1024] arrays. This cla
Hi guys,
There are two approaches I see in Lucene In Action about speeding up the
indexing process.
1) Simply increase the mergeFactor and RAMBufferSizeMB.
2) Using RAMDirectory as a buffer (perhaps even several in parallel) and later
merging it using addIndexes to FSDirectory.
So my question
Hi,
I am working on getting lucene indexing working on *Google App Engine*.
I am using a *ramdirectory* . I am facing a null pointer exception
when I *close
the indexwriter.*
I think that might have something to do with the fact that only the
following libraries are supported in google app engine
The reason is I have indexes on hard drive but want to load them into ram
for faster searching, adding, deleting, etc.
Using RAMDirectory can help achieve this goal.
On Thu, Jan 12, 2012 at 6:36 PM, Sanne Grinovero
wrote:
> Maybe you could explain why you are doing this? Someone could sugg
eem not related to the OpenMode.CREATE option.
>
>
> -- Original --
> From: "Ian Lea";
> Date: Wed, Jan 11, 2012 05:20 PM
> To: "java-user";
>
> Subject: Re: Build RAMDirectory on FSDirectory, and then synchronzing the
Subject: Re: Build RAMDirectory on FSDirectory, and then synchronzing the two
> I tried IndexWriterConfig.OpenMode CREATE, and the size is doubled.
Prove it.
--
Ian.
> The only way that is effective is the writer's deleteAll() methods.
>
> On Mon, Jan 9, 2012 at 5:23 AM, Ian Lea
> I tried IndexWriterConfig.OpenMode CREATE, and the size is doubled.
Prove it.
--
Ian.
> The only way that is effective is the writer's deleteAll() methods.
>
> On Mon, Jan 9, 2012 at 5:23 AM, Ian Lea wrote:
>
>> If you load an existing disk index into a RAMDirec
I tried IndexWriterConfig.OpenMode CREATE, and the size is doubled.
The only way that is effective is the writer's deleteAll() methods.
On Mon, Jan 9, 2012 at 5:23 AM, Ian Lea wrote:
> If you load an existing disk index into a RAMDirectory, make some
> changes in RAM and call ad
If you load an existing disk index into a RAMDirectory, make some
changes in RAM and call addIndexes to add the contents of the
RAMDirectory to the original disk index, you are likely to end up with
duplicate data on disk. Depending of course on what you've done to
the RAM index.
Sounds you
I'd better provide a snapshot of my code for people to understand my issues:
File file=new File("c:/index_files");
FSDirectory fsDir=new FSDirectory(file);
RAMDirectory ramDir=new RAMDirectory(fsDir, new
IndexWriterConfig(Version.LUCENE_35, new StandardAnalyzer());
Index
Hi,
I new a RAMDirectory based upon a FSDirectory. After a few modifications, I
would like to synchronize the two.
Some on the mailing list provided a solution that uses addIndex() function.
However, the FSDirectory simply combines with the RAMDirectory, and the
size doubled.
How can I do a
, Jan 2, 2012 01:30 PM
To: "java-user";
Subject: Re: How to use RAMDirectory more efficiently
will the solution provided by Charlie Hubbard do the work?
I am not sure I understand the "writer.addIndexes( ram );" part.
What if there are inconsistent data between FS an
nd some example that uses "Directory.write". But it doesn't look right to
me.
-- Original --
From: "Greg Steffensen";
Date: Mon, Jan 2, 2012 12:54 PM
To: "java-user";
Subject: Re: How to use RAMDirectory more efficientl
The two directories won't be synchronized. As the RAMDirectory JavaDocs
say:
Note that the resulting RAMDirectory instance is fully independent from the
original Directory (it is a complete copy). Any subsequent changes to the
originalDirectory will not be visible in the RAMDirectory ins
what about my code as follow:
FSDirectory indexDir = new NIOFSDirectory(new File("c:/index_folder"));
Directory ramDir = new RAMDirectory(indexDir);
IndexWriterConfig iwc = new IndexWriterConfig(Version.LUCENE_35,
new StandardAnalyzer(Version.LUCENE_35));
IndexWriter iw = new IndexWri
You can always index into RAMDirectory for speed then synchronize those
changes to the disk by adding the RAMDirectory to a FSDirectory at some
point. Here is a simple example of how to do that:
public void save( RAMDirectory ram, File dir ) {
FSDirectory fs = FSDirectory.open( dir
Hi,
Suppose that we have a huge amount of indices on hard drives but working in
RAMDirectory is a must, how can we decide which part of the indices to be
loaded into RAM, how to modify the indices, and when and how to synchronize
the indices with those on hard drives?
Any thoughts?
Thanks!
That was it, thanks!!!
Dean
-Original Message-
From: Ian Lea [mailto:ian@gmail.com]
Sent: Wednesday, June 22, 2011 2:35 AM
To: java-user@lucene.apache.org
Subject: Re: I have seen this exception on some posts around but don't see the
cause/solution(RamDirectory)..
At a gues
At a guess you are trying to open a searcher on a RAMDirectory that
doesn't yet contain anything. Files only get written when stuff is
added to an index and the writer is closed or committed.
--
Ian.
On Tue, Jun 21, 2011 at 11:43 PM, Hiller, Dean x66079
wrote:
> Anyone know how
Anyone know how to do a simple RamDirectory...I just created it but it is
failing with this...
Caused by: org.apache.lucene.index.IndexNotFoundException: no segments* file
found in org.apache.lucene.store.RAMDirectory@1d5a7f6
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@64804
Hello,
I came to similar conclusions, and have a similar comparison test
available here:
https://github.com/infinispan/infinispan/blob/master/lucene-directory/src/test/java/org/infinispan/lucene/profiling/PerformanceCompareStressTest.java
In my test I explicitly run the RAMDirectory first to
The RAMDirectory uses Java memory, an FSDirectory does not. Holding
Java memory makes garbage collection work harder. The operating system
is very very good at managing disk buffers, and does a better job
using spare memory than Java does.
For real-world sites, RAMDirectory is almost always
Makes sense. Thanks
-Original Message-
From: Toke Eskildsen [mailto:t...@statsbiblioteket.dk]
Sent: Tuesday, June 07, 2011 4:28 PM
To: java-user@lucene.apache.org
Subject: Re: RAMDirectory doesn't win over FSDirectory all the time, why?
On Mon, 2011-06-06 at 15:29 +0200, zhouchen
On Mon, 2011-06-06 at 15:29 +0200, zhoucheng2008 wrote:
> I read the lucene in action book and just tested the
> FSversusRAMDirectoryTest.java with the following uncommented:
> [...]Here is the output:
>
> RAMDirectory Time: 805 ms
>
> FSDirectory Time : 728 ms
This is
-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Tuesday, June 07, 2011 12:04 AM
To: java-user@lucene.apache.org
Subject: RE: RAMDirectory doesn't win over FSDirectory all the time, why?
Hi,
It depends on the Lucene version, so if the test uses latest Lucene on a
64bit OS, it ma
.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Monday, June 06, 2011 5:58 PM
> To: java-user@lucene.apache.org
> Subject: Re: RAMDirectory doesn&#
with the following uncommented:
>
>
>
> // /**
>
> // // change to adjust performance of indexing with FSDirectory
>
> writer.mergeFactor = 100;
>
> writer.maxMergeDocs = 99;
>
> writer.minMergeDocs = 1000;
>
> // */
>
>
>
;
writer.minMergeDocs = 1000;
//*/
Here is the output:
RAMDirectory Time: 805 ms
FSDirectory Time : 728 ms
Since I need to overwrite an old ramDirectory file and I don't want memory
leaks, I have the following code lines to close first the existing
RAMDirectory and create a new one.
INDEX_DIR.close();
INDEX_DIR = new RAMDirectory();
However, I get the following exception. Should I remove close()
Does this question make sense?
What I want is to compute term statistics over a corpus, and then use these
statistics when doing scoring + retrieval using a MemoryIndex or
RAMDirectory.
How can I do that?
Thanks,
Joseph
On Thu, Oct 28, 2010 at 8:06 PM, Joseph Turian wrote:
> How do I
How do I use MemoryIndex or RAMDirectory, but score using term statistics
from a corpus given during preprocessing?
Let's say I want to use a MemoryIndex or RAMDirectory to store a *single*
document, and then run a query against it, and get the score of the query
using just this one docume
rt of.
private int index(File indexDir, File dataDir, String suffix) throws Exception {
RAMDirectory ramDir = new RAMDirectory(); // 1
IndexWriter indexWriter = new IndexWriter(
ramDir,// 2
new SimpleAnalyzer(
you can't try. It's trivial to instantiate a
RAMdirectory
by calling the constructor with a Directory. See Ian's comment.
Best
Erick
On Tue, Oct 12, 2010 at 1:39 AM, wrote:
>
> I am also having a similar requirement .But its other way round.
>
> Basically ,I have ind
wrote:
> well actually I am doing a kind of a thesis regarding information
> retrieval.and my tutor wanted me to be able to create a program that
> firstly index a document in memory using RAMDirectory and then
> flushing it to disk using FSDirectory periodically. I was having a
> hard tim
Start by reading the javadocs for RAMDirectory.
--
Ian.
On Tue, Oct 12, 2010 at 6:39 AM, wrote:
>
> I am also having a similar requirement .But its other way round.
>
> Basically ,I have indexes in FSDirectory and which is transferred to
> another machine on regular basis.
I am also having a similar requirement .But its other way round.
Basically ,I have indexes in FSDirectory and which is transferred to
another machine on regular basis. But now for the reason of faster
searches, it would be better to copy the indexes onto RAM. (RAMDirectory).
Not sure of how it
well actually I am doing a kind of a thesis regarding information
retrieval.and my tutor wanted me to be able to create a program that
firstly index a document in memory using RAMDirectory and then
flushing it to disk using FSDirectory periodically. I was having a
hard time implementing it in my
Hey, Anshum
u mean Indexwriter based on RAMdirectory must be a singleton/static, yeah,
that works, finally success[?][?][?][?][?],
thanks a lot!
Regards
Hilly
2010/8/17 Anshum
> Hi Hilly,
> Seems like you are trying to use an already closed writer. Could you keep
> the writer
ne check this kind of sitation
> by itself?
>
>
> 2010/8/17 xiaoyan Zheng
>
> >
> > about RAMDirectory based B/S plantform problem
> >
> > hello, I just start to use lucene and become confused about RAMDirectory
> > based lucene index establishment, the probl
throw new AlreadyClosedException("this IndexWriter is closed");
}
}
how to avoid these kind of error? could lucene check this kind of sitation
by itself?
2010/8/17 xiaoyan Zheng
>
> about RAMDirectory based B/S plantform problem
>
> hello, I just start to use
about RAMDirectory based B/S plantform problem
hello, I just start to use lucene and become confused about RAMDirectory
based lucene index establishment, the problem is one user use this RAM to
establish index is ok, but, when it comes to multi user, the results is not
correct. when i use
Hi
> currently I'm working on a students project including a lucene index. It's a
> kind of search engine working on extracted data from the web.
> It's working pretty good, but now I'm curious about two things:
> - when is it usefull to use a RAMDirectory? Is the
Hi,
currently I'm working on a students project including a lucene index. It's a
kind of search engine working on extracted data from the web.
It's working pretty good, but now I'm curious about two things:
- when is it usefull to use a RAMDirectory? Is there a number of d
he time in both 'storages' ?
I know the one reason is to use RAMDirectory and FS and move the indexes
'by hand' but to do it i need two IndexWriters and two indexSearchers so i
have to join results. Is there any better way to do it?
rafal
-
regarding
> indexing.
> Does Lucene have got built-in mechanism to store indexes first in RAM and
> after some time or after some number of documents added to move them to FS?
> And searching docs all the time in both 'storages' ?
> I know the one reason is to use RAMDirector
d
> after some time or after some number of documents added to move them to FS?
> And searching docs all the time in both 'storages' ?
> I know the one reason is to use RAMDirectory and FS and move the indexes
> 'by hand' but to do it i need two IndexWriters an
'storages' ?
I know the one reason is to use RAMDirectory and FS and move the
indexes 'by hand' but to do it i need two IndexWriters and two
indexSearchers so i have to join results. Is there any better way to
do it?
rafal
--
1 - 100 of 264 matches
Mail list logo
