Hi,
I'm getting below exception while initializing FSDirectory-
Caused by: java.lang.IllegalAccessError: tried to access method
org.apache.lucene.store.MMapDirectory.unmapHackImpl()Ljava/lang/Object; from
class org.apache.lucene.store.MMapDirectory$$dtt &
Thanks Uwe, this will help us to clarify details and make a decision.
If you write your own data files into a given index directory, it is very
> likely that you may corrupt your index. In later Lucene versions (5.x) we
> are very strict with not allowing files in the index directory, which were
>
k.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Vlad K [mailto:kuzmi...@gmail.com]
> >
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Vlad K [mailto:kuzmi...@gmail.com]
> > Sent: Wednesday, September 02, 2015 8:07 AM
> > To: java-us
rom: Vlad K [mailto:kuzmi...@gmail.com]
> Sent: Wednesday, September 02, 2015 8:07 AM
> To: java-user@lucene.apache.org
> Subject: Lucene 5.2.1: FSDirectory, is it possible to open existing output for
> append?
>
> FSDirectory createOutput re-creates file because it opens stream w
FSDirectory createOutput re-creates file because it opens stream with
TRUNCATE_EXISTING. What is the way to open existing file and append data? I
used it at Lucene 4.1 to create store with raw messages. I could use
Files.newOutputStream directly to do that but I just want to understand
what is the
t; H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: sreedevi s [mailto:sreedevi.payik...@gmail.com]
> > Sent: Thursday, February 05, 2015 10:13 AM
> > To: java-user@lucene.apache.org
>
evi.payik...@gmail.com]
> Sent: Thursday, February 05, 2015 10:13 AM
> To: java-user@lucene.apache.org
> Subject: MMapDirectory or FSDirectory
>
> Hi,
> I am doing some performance analysis with lucene. I have 1 million resources
> with 1000 attributes.
> According to how I index
Hi,
I am doing some performance analysis with lucene. I have 1 million
resources with 1000 attributes.
According to how I index, I will have 1 million documents with 1000 fields.
For me the total data was about 100 GB and while using FSDirectory to store
my indices, index size was almost 6 GB.
I
ng RAMDirectory as a buffer (perhaps even several in parallel) and
> later merging it using addIndexes to FSDirectory.
>
> So my question is the following:
> In case I have only 1 thread with RAMDirectory - is that pretty much the same
> as method 1? Since it's in memory
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
thanks
On Wed, Feb 15, 2012 at 1:14 AM, Mihai Caraman wrote:
> you can use a fsdirectory for each writer and then, search on all of them
> at once. This is the recomended way if you have different apps.
>
> În data de 14 februarie 2012, 19:06, Ian Lea a scris:
>
> > You can
you can use a fsdirectory for each writer and then, search on all of them
at once. This is the recomended way if you have different apps.
În data de 14 februarie 2012, 19:06, Ian Lea a scris:
> You can only have one writer against one index at a time. Lucene's
> locking will preve
You can only have one writer against one index at a time. Lucene's
locking will prevent anything else.
--
Ian.
On Tue, Feb 14, 2012 at 4:49 PM, Cheng wrote:
> Hi,
>
> I need to manage multiple applications, each having its own writer yet on a
> same FSdirectory. How to make
ike RAMDirectory for
> >> small flushed segments.
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >> On Mon, Feb 6, 2012 at 10:45 AM, Cheng wrote:
> >> > Uwe, when I meant speed is slow, I didn'
>>
>> Also, you can use NRTCachingDirectory which acts like RAMDirectory for
>> small flushed segments.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Mon, Feb 6, 2012 at 10:45 AM, Cheng wrote:
>> > Uwe, when I
all flushed segments.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Feb 6, 2012 at 10:45 AM, Cheng wrote:
> > Uwe, when I meant speed is slow, I didn't refer to instant visibility of
> > changes, but that the changes may be synchronized with FSDirecto
MDirectory for
small flushed segments.
Mike McCandless
http://blog.mikemccandless.com
On Mon, Feb 6, 2012 at 10:45 AM, Cheng wrote:
> Uwe, when I meant speed is slow, I didn't refer to instant visibility of
> changes, but that the changes may be synchronized with FSDirectory when
; > To: java-user@lucene.apache.org
> > Subject: Re: Configure writer to write to FSDirectory?
> >
> > Uwe, when I meant speed is slow, I didn't refer to instant visibility of
> changes,
> > but that the changes may be synchronized with FSDirectory when I us
My original question is if there exists a way to configure writer when to
writer to FSDirectory. I think there may be something in
the IndexWriterConfig that can helps.
On Mon, Feb 6, 2012 at 11:50 PM, Ian Lea wrote:
> Well, yes. What would you expect? From the javadocs
...@thetaphi.de
> -Original Message-
> From: Cheng [mailto:zhoucheng2...@gmail.com]
> Sent: Monday, February 06, 2012 4:45 PM
> To: java-user@lucene.apache.org
> Subject: Re: Configure writer to write to FSDirectory?
>
> Uwe, when I meant speed is slow, I didn't refe
t; changes, but that the changes may be synchronized with FSDirectory when I
> use writer.commit().
>
> When I use RAMDirectory, the writer.commit() seems much faster than using
> NRTManager built upon FSDirectory. So, I am guessing the difference is the
> index synchronization.
>
&
h the FSDirectory. The slower speed
of using NRTManager built upon FSDirectory may be caused by the frequent
updates or modification of indexes.
That is my guess.
On Mon, Feb 6, 2012 at 11:41 PM, Ian Lea wrote:
> What exactly do you mean by the "speed is slower"? Time taken to
> up
Uwe, when I meant speed is slow, I didn't refer to instant visibility of
changes, but that the changes may be synchronized with FSDirectory when I
use writer.commit().
When I use RAMDirectory, the writer.commit() seems much faster than using
NRTManager built upon FSDirectory. So, I am gue
>>
>>> >> All thread safe so you don't have to worry about any complications
>>> >> there. And I bet it'll be blindingly fast.
>>> >>
>>> >> Don't forget to close() things down at the end.
>>> >>
>>
://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Cheng [mailto:zhoucheng2...@gmail.com]
> Sent: Monday, February 06, 2012 4:27 PM
> To: java-user@lucene.apache.org
> Subject: Re: Configure writer to write to FSDirectory?
>
> Ian,
>
> I encounte
rry about any complications
>> >> there. And I bet it'll be blindingly fast.
>> >>
>> >> Don't forget to close() things down at the end.
>> >>
>> >>
>> >> --
>> >> Ian.
>> >>
>> &g
t;>
> >> On Mon, Feb 6, 2012 at 12:15 AM, Cheng wrote:
> >> > I was trying to, but don't know how to even I read some of your blogs.
> >> >
> >> > On Sun, Feb 5, 2012 at 10:22 PM, Michael McCandless <
> >> > luc...@mikemcc
t;> > On Sun, Feb 5, 2012 at 10:22 PM, Michael McCandless <
>> > luc...@mikemccandless.com> wrote:
>> >
>> >> Are you using near-real-time readers?
>> >>
>> >> (IndexReader.open(IndexWriter))
>> >>
>> >> Mike McCand
p://blog.mikemccandless.com
> >>
> >> On Sun, Feb 5, 2012 at 9:03 AM, Cheng wrote:
> >> > Hi Uwe,
> >> >
> >> > My challenge is that I need to update/modify the indexes frequently
> while
> >> > providing the sear
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Sun, Feb 5, 2012 at 9:03 AM, Cheng wrote:
>> > Hi Uwe,
>> >
>> > My challenge is that I need to update/modify the indexes frequently while
>> > providing the searc
//blog.mikemccandless.com
>
> On Sun, Feb 5, 2012 at 9:03 AM, Cheng wrote:
> > Hi Uwe,
> >
> > My challenge is that I need to update/modify the indexes frequently while
> > providing the search capability. I was trying to use FSDirectory, but
> found
> >
ility. I was trying to use FSDirectory, but found
> out that the reading and writing from/to FSDirectory is unbearably slow. So
> I now am trying the RAMDirectory, which is fast.
>
> I don't know of MMapDirectory, and wonder if it is as fast as RAMDirectory.
>
>
> On Sun,
Hi Uwe,
My challenge is that I need to update/modify the indexes frequently while
providing the search capability. I was trying to use FSDirectory, but found
out that the reading and writing from/to FSDirectory is unbearably slow. So
I now am trying the RAMDirectory, which is fast.
I don't
.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Cheng [mailto:zhoucheng2...@gmail.com]
> Sent: Sunday, February 05, 2012 7:56 AM
> To: java-user@lucene.apache.org
> Subject: Configure writer to write to FSD
Seem 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 synchr
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'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
&
t; index or overwrite the original. IndexWriterConfig.OpenMode CREATE.
>
>
> --
> Ian.
>
>
> On Mon, Jan 9, 2012 at 4:29 AM, dyzc <1393975...@qq.com> wrote:
> > I'd better provide a snapshot of my code for people to understand my
> issues:
> >
> &g
>
> File file=new File("c:/index_files");
> FSDirectory fsDir=new FSDirectory(file);
> RAMDirectory ramDir=new RAMDirectory(fsDir, new
> IndexWriterConfig(Version.LUCENE_35, new StandardAnalyzer());
>
>
> IndexWriter iw = new IndexWriter(ramDir, iwc);
>
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
just use the static factory method FSDirectory#open(File) to obtain a
FSDirectory instance
simon
On Wed, Aug 24, 2011 at 3:55 PM, Mostafa Hadian wrote:
> hello.
> there is this piece of code in the book "lucene in action" :
> Directory dir = new FSDirectory(new File(inde
Hi Mostafa,
Try looking through the API for help with these types of questions:
http://lucene.apache.org/java/3_3_0/api/all/org/apache/lucene/store/FSDi
rectory.html
You can use a number of FSDirectory subclasses depending on your
circumstances.
Hope this helps!
Jason
-Original Message
hello.
there is this piece of code in the book "lucene in action" :
Directory dir = new FSDirectory(new File(indexDir), null);
but class FSDirectory is an abstract class and cannot be instantiated like
this.
thank you very much for your helping.
Hey,
you are right FSDirectory is abstract, yet the fact that it doesn't
declare an abstract method doesn't make it wrong. Please use the
static factory methods FSDirectory.open(File) to create an instance.
This factory will create a reasonable default for your platform. see
the j
Greeting,
There's a mistake in writing the type of the class FSDirectory in the core
of Lucene 3.3. This class is defined as an abstract one while No abstract
method is found inside. Also it yields some other problems like not being
able to create an instance of FSDirectory in the code.
P
there's enough memory, my conclusion is that when you have
memory, you should limit the JVM heap and leave that to the OS to make
better use of FSDirectory, as this implementation is really well
optimized, at least for local disks.
When you don't have enough available memory, I would s
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;
>
> // */
>
>
>
I read the lucene in action book and just tested the
FSversusRAMDirectoryTest.java with the following uncommented:
///**
//// change to adjust performance of indexing with FSDirectory
writer.mergeFactor = 100;
writer.maxMergeDocs = 99
to work with, but, for only 80K docs it
should be possible as long as the docs are not large.
Mike
http://blog.mikemccandless.com
On Mon, Apr 4, 2011 at 6:39 AM, Claudio R wrote:
> Hi,
>
> I am using Lucene 2.9.4 with FSDirectory.
> My index has 80 thousand documents (each document h
Hi,
I am using Lucene 2.9.4 with FSDirectory.
My index has 80 thousand documents (each document has 12 fields).
My jvm has 70Mb of RAM memory (limited by my hosting).
I am getting various OutOfMemoryError.
I ran jmap and I got:
num #instances #bytes Class description
Hi,
I am using Lucene 2.9.4 with FSDirectory.
My index has 80 thousand documents (each document has 12 fields).
My jvm has 70Mb of RAM memory (limited by my hosting).
I am getting various OutOfMemoryError.
I ran jmap and I got:
num #instances #bytes Class description
Hi,
I am using Lucene 2.9.4 with FSDirectory.
My index has 80 thousand documents (each document has 12 fields).
My jvm has 70Mb of RAM memory (limited by my hosting).
I am getting various OutOfMemoryError.
I ran jmap and I got:
num #instances #bytes Class description
Ok Erick,
Thanks for your quick answer.
FSDirectory will, indeed, store the index on disk. However,
when *using* that index, lots of stuff happens. Specifically:
When indexing, there is a buffer that accumulates documents
until it's flushed to disk. Are you indexing?
When searching (and
FSDirectory will, indeed, store the index on disk. However,
when *using* that index, lots of stuff happens. Specifically:
When indexing, there is a buffer that accumulates documents
until it's flushed to disk. Are you indexing?
When searching (and this is the more important part), various
c
Hi,
I am using Lucene 2.9.4 with FSDirectory.
My index has 80 thousand documents (each document has 12 fields).
My jvm has 70Mb of RAM memory (limited by my hosting).
I am getting various OutOfMemoryError.
I ran jmap and I got:
num #instances#bytesClass description
Hi,
you can export index with jar itself
and do not provide absolute path relative to file system
instead create folder named index in your project space
then as below you can get index directory
directory=FSDirectory.open(new File("index"));
here path is relative to you workspace which will not
Hi,
I need to generate executable JAR.
In my code, it has some lines as following:
String path = "d:\\project\\";
File f = new File(path);
Directory dir = FSDirectory.open(f);
In the path, there is a wordnet index which is used to search by synonyms.
When I run the JAR, it needs local directory
? what's the best solution to copy directory from
RAMDirectory to FSDirectory besides using copy? thanks.
http://stackoverflow.com/questions/3913180/how-to-integrate-ramdirectory-into-fsdirectory-in-lucene/3923914#3923914
--
http://jacobian.web.id
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
MakMak wrote:
Hey Mike, thanks for the quick response, I tried passing Directory to
IndexReader.open() and there were no deadlocks!! I will get rid of
synchronizing on FSDirectory too.
Great!
However do you think it will be better to modify the docs for
FSDirectory
and remove the sync
Hey Mike, thanks for the quick response, I tried passing Directory to
IndexReader.open() and there were no deadlocks!! I will get rid of
synchronizing on FSDirectory too.
However do you think it will be better to modify the docs for FSDirectory
and remove the sync part of "Directorie
mentReader lock.
Thread2 -
1. Issues prevIndexReader.close() which locks a MultiSegmentReader
and then
goes ahead and waits on a lock for FSDirectory
Actual code:
Thread 1->
at
org
.apache
.lucene.index.DirectoryIndexReader.reopen(DirectoryIndexReader.java:
85)
- wa
prevIndexReader.close() which locks a MultiSegmentReader and then
goes ahead and waits on a lock for FSDirectory
Actual code:
Thread 1->
at
org.apache.lucene.index.DirectoryIndexReader.reopen(DirectoryIndexReader.java:85)
- waiting to lock <0xfffecaba16
is create some kind of marker for whether your app was
gracefully shut down. Then, when gracefully shutting down,
use Directory.copy to copy FROM your RAMDir TO your
FSDir.
Upon startup, you can check your marker and, if all is well,
read your FSDirectory into your RAMDir, and away you go.
If yo
Hi,
I have a RAMDirectory based index. The document source for the index is
a database table, where content to be indexed is stored alongside a
status (pending_index, indexed, pending_delete, deleted). Each time the
application is started, and periodically thereafter, all documents from
the databa
OK I opened:
https://issues.apache.org/jira/browse/LUCENE-1331
Mike
Paul Taylor wrote:
Michael McCandless wrote:
Hmmm, you should not close the directory if you are then going to
use it to instantiate a searcher.
how come it works ?
Your code below never closes the searcher? I th
It works because Lucene doesn't currently check for it, and, because
closing an FSDirectory does not actually make it unusable. In fact it
also doesn't catch a double-close call.
But it may cause subtle problems, because FSDirectory has this
invariant: only a single i
Michael McCandless wrote:
Hmmm, you should not close the directory if you are then going to use
it to instantiate a searcher.
how come it works ?
Your code below never closes the searcher? I think that is most
likely the source of your file descriptor leaks.
Ok fixed
paul
--
documentation is not very clear on this point. I see your
poibnt about the try/finally I'll make that chnage.
There are many other parts of the code that use filedescriptors, but
the problem has never occurred before moving to a FSDirectory
thanks paul
heres an example of my sea
I'll make that chnage.
There are many other parts of the code that use filedescriptors, but
the problem has never occurred before moving to a FSDirectory
thanks paul
heres an example of my search code, is this ok ?
public boolean recNoColumnMatchesSearch(Integer columnId, Integer
see your poibnt about
the try/finally I'll make that chnage.
There are many other parts of the code that use filedescriptors, but the
problem has never occurred before moving to a FSDirectory
thanks paul
heres an example of my search code, is this ok ?
public boolean recNoColumnMatchesSea
Technically you should call directory.close() as well, but missing
that will not lead to too many open files.
How often is that RuntimeException being thrown? EG if a single
document is frequently hitting an exception during analysis, your code
doesn't close the IndexWriter in that situa
Hi, I have been using a RAMDirectory for indexing without any problem,
but I then moved to a file based directory to reduce memory usage. this
has been working fine on Windows and OSX and my version of linux
(redhat) but is failing on a version of linux (archlinux) with 'Too many
files opened'
Hi Devashish,
The difference between these modes of operation would be that firsly,
RAMDirectory and FSDirectory on one hand are implementations of the
directory class of lucene.
http://lucene.apache.org/java/2_2_0/api/org/apache/lucene/store/Directory.html
Lucene's directory is just a flat
What is the difference between these three modes of operating with
lucene... And are there any other modes/ways of operation also, using
which we can more effectively run applications with lucene.
I have heard there is also something called 'Memory' in contrib
directory of lucene source package wh
> OG: again, it depends. If the index you'd get by merging is
> of manageable size, then merge your indices.
OK, this is what I tought.
A single index should be faster than multiple indexes with a MultiSearcher,
right?
But what about the ParallelMultiSearcher? As I understand the docs it
searc
Hi,
- Original Message
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Sunday, January 13, 2008 12:41:18 PM
Subject: Max size of index (FSDirectory )
Hi,
is there any maximum size for an index?
OG: There is: doc IDs are currently
Hi,
is there any maximum size for an index?
Are there any recommendations for a useful max size?
I want to index in parallel. So I have to create multiple indexes.
Shall I merge them together or shall I let them as they are using
(Parallel)MultiSearcher?
Thank you.
---
This is from Lucene's CHANGES.txt:
LUCENE-773: Deprecate the FSDirectory.getDirectory(*) methods that
take a boolean "create" argument. Instead you should use
IndexWriter's "create" argument to create a new index.
(Mike McCandless)
So you should create the FSDir with
FSDirect
In general it is much nicer to say "I did not make myself clear" than "you
are not getting me"
If you look on the java doc page for FSDirectory it tells you what do do
instead of the deprecated method:
getDirectory(File file, boolean create)
Deprecated. Use
No you are not getting me. I have this original code. What i should use
instead of this code to create a directory, because the dir
=FSDirectory.getDirectory(indexDir, true) is deprecated.
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.FSDirectory;
protected Directo
x27;s create flag, instead, to create a
new index.
*But I'd expect the same behavior from IndexWriter with the create flag...
Best
Erick
On Nov 30, 2007 8:34 AM, Liaqat Ali <[EMAIL PROTECTED]> wrote:
> I m facing problem with this code..
>
> dir = new FSDirectory();
>
I m facing problem with this code..
dir = new FSDirectory();
dir.getDirectory(indexDir, true);
i get error that FSDirectory has protected access. So what i should use
instead of it...
Liaqat
-
To unsubscribe, e-mail
change any classes of Lucece: Add the "implements Serialzable" in
> any classes.
>
>
>
>
> On Nov 27, 2007 4:28 AM, Chhabra, Kapil <[EMAIL PROTECTED]> wrote:
>
> > > one can improve search performance by using a RAMDirectory created
> > from an
RAMDirectory has a constructor that takes in another Directory and
loads it into memory. No Serialization necessary. Just index to a
FSDirectory using Lucene's normal indexing methods (it takes care of
buffering them internally) and then load the FSDirectory into a
RAMDirectory. H
07 4:28 AM, Chhabra, Kapil <[EMAIL PROTECTED]> wrote:
> > one can improve search performance by using a RAMDirectory created
> from an underlying FSDirectory using one of the parameterised
> constructors. Is this correct?
> Absolutly
>
> > Will a FSDirectory not automatical
> one can improve search performance by using a RAMDirectory created
from an underlying FSDirectory using one of the parameterised
constructors. Is this correct?
Absolutly
> Will a FSDirectory not automatically load the index into memory
provided enough RAM is available?
Not all index fil
Hi there,
I am using currently a FSDirectory to build my index. The reason for using
a file system based index is that a full index rebuild takes around 30
minutes and I want to keep a persistent index.
In 'Lucene in Action' I've read that one can improve search performan
1 - 100 of 119 matches
Mail list logo
