Thank you, Yonik, it seems this is the case.
What can we do in this case? Would running the program with java -d32 be
a solution?
Thanks again,
roxana
One possibility: if lucene runs out of memory while adding or optimizing, it
can leave unused files beind that increase the size of the index. A 64 bit
JVM will require more memory than a 32 bit one due to the size of all
references being doubled.
If you are using the compound file format (the default - check for .cfs
files), then it's easy to check if you have this problem by seeing if there
are any *.f* files in the index directory. These are intermediate files and
shouldn't exist for long in a compound-file index.
-Yonik
Now hiring -- http://tinyurl.com/7m67g
On 10/20/05, Roxana Angheluta <[EMAIL PROTECTED]> wrote:
Hi everybody!
We have a large Lucene index which gets updated very often.
Until recently the java virtual machine used to manage the index was on
32 bits, although the program was running on a 64bits station. Last week
we changed the java to 64 bits and since then we experience strange
problems, the index grows very large. I'm not sure the 2 are related,
that's why I ask here: is it possible that the index got corrupted
after we updated the jvm? Is there any relation between the size of the
index and the jvm used?
I hope the questions make sense, thanks,
roxana
---------------------------------------------------------------------
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]
