i feel confident in the delete sequence. i will run the things you ask for
though. this does work on my laptop.
the code that changed was some update method that was used in the first
release. so before the only writes needed were done by this and it wholesale
replaces. whereas the new feature updates documents. it worked fine in
testing. and i look at the product of this method in other environments and
they all have segment files and update fine. i do appreciate your
response though. at least i have things to do to move this forward now. i
will print out all the paths that get touched by this delete block, and the
results of ech delete(). its good to get rid of possibilities.
baring this being the problem.. what would cause lucene to delete its segment
file?
--JN
: : if (!newPath.equals(subDirs[i].getPath())) {
part keeps it out of the new path. no, the boxes have different windows
operating systems. probobly a slight difference in jvm.
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Chris Hostetter
Sent: Sat 1/28/2006 2:37 AM
To: java-user@lucene.apache.org
Subject: RE: problem updating a document: no segments file?
: this code works in a couple other boxes as is. that deleting code
Are those boxes running the same OS? The same JVM?
: removes the active index after this one builds in a different location.
: then the searcher is told to make this newest one the current and the
: old one is deleted. it effects directories and their entire contents.
: it wouldnt select just a segment file. also, like i said, this runs
I'm not convinced.
If your getIndexDirectory() method is returning a string from a config
file (or something like that) and it includes a trailing seperator (in
addition to the seperator your code adds) then the index directory would
be created fine (if i remember right, extra seperates don't generate an
exception) but your string equality test would fail and you'd try to
delete the files in the directory you just created.
If your searcher has already opened some of the files, then (depending on
your OS) the delete code may not be able to delete them -- you're not
checking the return value from subFiles[j].delete() so you have no way of
knowing. The segments file may be the only file getting deleted, because
it may be the only file your searcher doesn't have open at the moment the
delete code runs. If i remember right IndexSearcher only opens the
segments file to get a list of all the individual segments, and then
immdeiately closes it, but keeps the rest of hte files open permenantly.
: fine on my laptop and g5. and actually, this code was fine till
: recently on that box. i modified a different method and updated the
: code to this server and now i have this problem.
what was the code that changed?
: : String newPath = getIndexLocation() + File.separator +
: : System.currentTimeMillis();
: :
: : IndexWriter writer = new IndexWriter(new File(newPath),
: : analyzer, true);
:
: ...
:
: : writer.optimize();
: : writer.close();
: :
: : SearchSO.setSearcher(newPath);
: :
: : File[] subFiles;
: : File[] subDirs = new File(getIndexLocation()).listFiles();
: :
: : for (int i=0;i<subDirs.length;i++) {
: : if (subDirs[i].isDirectory()) {
: : if (!newPath.equals(subDirs[i].getPath())) {
: : subFiles = subDirs[i].listFiles();
: : for (int j=0;j<subFiles.length;j++) {
: : subFiles[j].delete();
: : }
: : subDirs[i].delete();
: : }
: : }
: : }
: :
: :
: : }
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
