lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Mannion" <chris.mann...@nonstopgov.com>
Subject index ignoring updates
Date Wed, 17 Sep 2008 16:45:04 GMT
Hi All

I'm having a problem with our lucene index and wondering if anyone else has
encountered anything similar or has any idea of what I might look at to find
the cause/solution.  We had a working tomcat setup in which records were
regularly uploaded into a lucene index, each upload removed old records from
the index and inserted new ones, and a website running on the tomcat server
had a page to search and display records from that index.  Recently the
whole setup has been moved to a new server by simply copying the complete
tomcat directory across (the lucene index files are stored within the tomcat
directory structure) and since then the process has fallen appart, uploads
are still loaded in as before, removing old data and inserting new, without
any errors occuring and with the insert and remove calls returning the
correct numbers of records processed, but when we search the index, it seems
as though no uploads have been done, the data the search returns is the old
data.  Even more oddly, monitoring the numbers of records in the index as
reported by the upload process seems to imply that the data is changing
correctly, but the search doesn't reflect this.

For example, originally the index contained 1292 records of a certain type.
On uploading a new set of 1219 of the records, the index reported that 1292
of that type had been removed and 1219 inserted.  Subsequent uploads of the
same new set of data reported that 1219 records had been dropped from the
index and again 1219 inserted, implying that the initial upload had worked
as expected.  However, the search still continue to find 1292 records.  We
flush and optimize the index after each upload and for the past year the
system has worked fine, it's only since being copied onto a new server that
this odd behaviour has started.  Any ideas would be gratefully received, I'm
completely puzzled.

-- 
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message