All, Thank you all again for your input yesterday.
Today we are considering a two part approach. Eventually, we will evaluate whether to port to JCC pyLucene, or to bite the bullet and go the full Java Lucene route. The GCJ version has served us well in a single thread app, and we believe a JCC version will work great, but sorting out the JCC/windows build process may be more risky for us than simply implementing Java Lucene, with all its horrors. [Simply? Did I just say that?] But First we will build a periodic restart mechanism for our GCJ implementation. Except for the leak, this system is VERY fast and functionally complete, so we want to see it through [as do our paid subscribers!] The secret will be to find a metric which can reliably predict an impending failure.. -time- is the most basic, but we would prefer something a little more reliable/referential. Number of queries? RAM? [seems to plateau and remain stable for a while, so this probably doesn't help] Incidence of a particular error message which completes a search but presages the subsequent search failure? Any process signature which can be monitored, without indicating an ACTUAL failure has already occurred. Pete, it looks like you used this solution for a while as well.. did you just restart on a schedule, or were you able to monitor for a predictive event? Also, you restarted the process/service, but did you have to restart the machine periodically as well, or was your solution stable without machine restarts? [if restarting a service every hour can be called stability.] All the best for thanksgiving, and again, our thanks to our helpful respondents. Bill Joe _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
