RE: Memory eaten up by String, Term and TermInfo?

I'll try later and report back ASAP. You know, it takes days to cause OOM. Thank you all! Gong > -Original Message- > From: Michael McCandless [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 14, 2008 10:28 PM > To: java-user@lucene.apache.org > Subject: Re: Memory eaten up by String,

Re: Memory eaten up by String, Term and TermInfo?

Small correction: it was checked in this morning (at least, on the East Coast of the US). So you need to either build your own JAR using Lucene's trunk, or, wait for tonite's build to run and then download the build artifacts from here: http://hudson.zones.apache.org/hudson/job/Luce

Re: Memory eaten up by String, Term and TermInfo?

Can you try to update to the latest Lucene svn version, like yesterday? LUCENE-1383 was checked in yesterday. This patch is addressing a leak problem particular to J2EE applications. -- Chris Lu - Instant Scalable Full-Text Search On Any Database/Application site: http://w

Re: Frequently updated fields

It would be good to allow users to use their own Filter subclasses in SOLR. This will help with RMI based implementations that use SOLR, and will allow all of the open source Filter work to be used in SOLR, without needing to recreate it with DocSets. 2008/9/14 Gerardo Segura <[EMAIL PROTECTED]>:

Re: follow up of Lucene out of memory with RAMDirectory on J2EE environment

I just committed this, so the fix will be in 2.4. Thanks for raising this Chris! Mike Chris Lu wrote: Just confirmed the fix for this problem is ready in patch LUCENE-1383 Thanks Robert Engels for arguing with me and understand the problem

Re: Frequently updated fields

I had similar requirements: some fields didn't required text processing, there were just used as filters to focus the search on subset of documents in solr. As Karl suggested, implementing a filter was the most direct approach for me. The issue was that, not been familiar myself with solr, I c