Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 88610 invoked from network); 17 Sep 2008 16:45:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Sep 2008 16:45:53 -0000 Received: (qmail 21840 invoked by uid 500); 17 Sep 2008 16:45:44 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 20990 invoked by uid 500); 17 Sep 2008 16:45:43 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 20979 invoked by uid 99); 17 Sep 2008 16:45:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Sep 2008 09:45:43 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [66.249.92.168] (HELO ug-out-1314.google.com) (66.249.92.168) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Sep 2008 16:44:44 +0000 Received: by ug-out-1314.google.com with SMTP id j3so556008ugf.23 for ; Wed, 17 Sep 2008 09:45:05 -0700 (PDT) Received: by 10.67.98.15 with SMTP id a15mr2320824ugm.15.1221669904780; Wed, 17 Sep 2008 09:45:04 -0700 (PDT) Received: by 10.66.251.14 with HTTP; Wed, 17 Sep 2008 09:45:04 -0700 (PDT) Message-ID: <11e852b50809170945y5bdafa01q286eaab56911557f@mail.gmail.com> Date: Wed, 17 Sep 2008 17:45:04 +0100 From: "Chris Mannion" To: java-user@lucene.apache.org Subject: index ignoring updates MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12941_25101758.1221669904791" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_12941_25101758.1221669904791 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ------=_Part_12941_25101758.1221669904791--