Thanks Doron. The site you provided doesn't support firefox, that's why had
problem with downloading.
Your code works fine and I've just noticed I didn't change the create
parameter to false when I've leaned the index directory. Sorry for my
mistake.
Thanks a lot for your help Doron. You advic
> can't access the file:
> http://cdoronc.20m.com/tmp/indexingThreads.zip
Yes, this Web host sometimes behaves strange when clicking a link from a
mail program. Please try to copy
cdoronc.20m.com/tmp
to the Web Browser (e.g. Firefox), click .
This should show the content of that tmp folder, inc
can't access the file:
Forbidden
Remote Host: [62.172.205.164]
You do not have permission to access
http://cdoronc.20m.com/tmp/indexingThreads.zip
Data files must be stored on the same site they are linked from.
Thank you for using 20m.com
--
View this message in context:
http://www.nabble.
> I did clean everything but still getting the same problem. I'm using
lucene
> 2.0. Do you get the same problem on your machine?
Please try with this code - http://cdoronc.20m.com/tmp/indexingThreads.zip
Regards,
Doron
-
To un
I did clean everything but still getting the same problem. I'm using lucene
2.0. Do you get the same problem on your machine?
--
View this message in context:
http://www.nabble.com/modify-existing-non-indexed-field-tf1905726.html#a5288759
Sent from the Lucene - Java Users forum at Nabble.com.
> I've tried changing to one indexing thread
> (instead of 5) but still get the same problem. can't figure out why this
> happens.
The program as listed seems to accesss an existing index - since 'create'
is always for both 'FSDirectory.getDirectoy(,)' and 'new
IndexWriter(,,)'. Perhaps an old lo
Thanks for your advice Doron. I've tried changing to one indexing thread
(instead of 5) but still get the same problem. can't figure out why this
happens.
--
View this message in context:
http://www.nabble.com/modify-existing-non-indexed-field-tf1905726.html#a5266343
Sent from the Lucene - Java
The lock time out exception is caused by trying to open multiple
IndexWriter objects in parallel - each of the 5 threads is creating its own
IndexWriter object in each invocation of addAndIndex(). This cannot work -
I think that chapter 2.9 of "Lucene in Action" is essential reading for
fixing this
Here is the simplified code that causes problem (Lock obtain timed out).
MyIndexer is used for indexing and searching. IndexTest starts 5 threads for
indexing and 100 threads for searching.
MyIndexer.java
public class MyIndexer
{
File m_IndexFile;
IndexReader m_IndexReader;
Directory
> The problem I've had before was that I set my writer to null
> right after close it. That's why I got lock timeout exception
> when i try to create a the writer again. Guess I just need
> to close it, and re-open it would avoid the
> locking problems then.
It is valid to nullify the just closed
Thanks a lot Doron. I'm gonna give it a try now. The problem I've had before
was that I set my writer to null right after close it. That's why I got lock
timeout exception when i try to create a the writer again. Guess I just need
to close it, and re-open it would avoid the locking problems then.
> From what you said, I'm thinking of switching to IndexModifier.
Yes, IndexModifier would synchronize add/delete. One should notice the
performance comment in IndexModifier
http://lucene.apache.org/java/docs/api/org/apache/lucene/index/IndexModifier.html
- "While you can freely mix calls to add
Thanks a lot Doron.
I thought I had to close all readers and searchers in order to new
IndexWriter, otherwise I keep getting Lock timeout exception in a
multithreaded environment. In my case, modifying/adding/deleting only
happens occasionally, so I don't have a IndexWritter that is open all the
On Samstag 08 Juli 2006 00:03, dan2000 wrote:
> When you do re-index, you'll have to close the reader, which
> would pause the search. Any better way of doint it?
Try using IndexModifier (added in Lucene 1.9).
Regards
Daniel
--
http://www.danielnaber.de
--
> dan2000 <[EMAIL PROTECTED]> wrote on 07/07/2006 15:03:35:
> but if you remove it and add it again, you'll need to re-index it again.
> don't you? When you do re-index, you'll have to close the reader, which
> would pause the search. Any better way of doint it?
INHO yes and no -
There's no need
but if you remove it and add it again, you'll need to re-index it again.
don't you? When you do re-index, you'll have to close the reader, which
would pause the search. Any better way of doint it?
--
View this message in context:
http://www.nabble.com/modify-existing-non-indexed-field-tf1905726.
Yes, you can do something like that, but of course you have to delete the old
Document, and add the new, modified oneto the index, too. I do something like
that on one of the Simpy.com indices and it works nicely.
Otis
- Original Message
From: dan2000 <[EMAIL PROTECTED]>
To: java-user
I don't think you've done anything to the index. This code is really
equivalent to something like
Field field = hits.doc(i).getField('address");
field.set("11 Diana Street");
You've changed the value of the field instance, but that is essentially a
local variable (even though not explicit in you
18 matches
Mail list logo
