lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: [Lucene.Net] Re: Memory Leak in 2.9.2.2
Date Wed, 30 Nov 2011 17:26:29 GMT
Trevor,

I'm not sure if you can use 2.9.4, though, it looks like you're using
VS2005 and .NET 2.0.  2.9.4 targets .NET 4.0, and I'm fairly certain we use
classes only available in 4.0 (or 3.5?).  However, if you can, I would
suggest updating, as 2.9.4 should be a fairly stable release.

The leak I'm talking about is addressed here:
https://issues.apache.org/jira/browse/LUCENE-2467, and the ported code
isn't available in 2.9.2, but I've confirmed the patch is in 2.9.4.  It may
or may not be what your issue is.  You say that it was at one time working
fine, I assume you mean no memory leak.  I would take some time to see what
else in your code has changed.  Make sure you're calling Close on whatever
needs to be closed (IndexWriter/IndexReader/Analyzers, etc).

Unfortunately for us, memory leaks are hard to debug over email, and it's
difficult for us to tell if it's any change to your code or an issue with
Lucene .NET.  As far as I can tell, this is the only memory leak I can find
that affects 2.9.2.


Thanks,
Christopher

On Wed, Nov 30, 2011 at 8:25 AM, Prescott Nasser <geobmx540@hotmail.com>wrote:

> We just released 2.9.4 - the website didn't update last night, so ill have
> to try and update it later today. But if you follow the link to download
> 2.9.2 dist you'll see folders for 2.9.4.
>
> I'll send an email to the user and dev lists once i get the website to
> update
> ________________________________
> From: Trevor Watson
> Sent: 11/30/2011 8:14 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Re: Memory Leak in 2.9.2.2
>
> You said "pre 2.9.3"  I checked the apache lucene.net page to try to see
> if
> I could get a copy of 2.9.3, but it was never on the site, just 2.9.2.2 and
> 2.9.4(g).  Was this an un-released version?  Or am I looking in the wrong
> spot for updates to lucene.net?
>
> Thanks for all your help
>
> On Tue, Nov 29, 2011 at 2:59 PM, Trevor Watson <
> powersearchsoftware@gmail.com> wrote:
>
> > I can send you the dll that I am using if you would like.  The documents
> > are _mostly_ small documents.  Emails and office docs size of plain text
> >
> >
> > On Tuesday, November 29, 2011, Christopher Currens <
> > currens.chris@gmail.com> wrote:
> > > Do you know how big the documents are that you are trying to
> > delete/update?
> > >  I'm trying to find a copy of 2.9.2 to see if I can reproduce it.
> > >
> > >
> > > Thanks,
> > > Christopher
> > >
> > > On Tue, Nov 29, 2011 at 9:11 AM, Trevor Watson <
> > > powersearchsoftware@gmail.com> wrote:
> > >
> > >> Sorry for the duplicate post. I was on the road and posted both via my
> > web
> > >> mail and office mail by mistake
> > >>
> > >> The increase is a very gradual,  the program starts at about 160,000k
> > >> according to task manager (I know that's not entirely accurate, but it
> > was
> > >> the best I had at the time) and would, after adding 25,000-40,000
> > result in
> > >> an out of memory exception (800,000k according to taskmanager). I
> tried
> > >> building a copy of 2.9.4 to test, but could not find one that worked
> in
> > >> visual studio 2005
> > >>
> > >> I did notice using Ants memory profiler that there were a number of
> > >> byte[32789] arrays that I didn't know where they came from in memory.
> > >>
> > >> On Monday, November 28, 2011, Christopher Currens <
> > currens.chris@gmail.com
> > >> >
> > >> wrote:
> > >> > Hi Trevor,
> > >> >
> > >> > What kind of memory increase are we talking about?  Also, how big
> are
> > the
> > >> > documents that you are indexing, the ones returned from
> > getFileInfoDoc()?
> > >> >  Is it putting an entire file into the index?  Pre 2.9.3 versions
> had
> > >> > issues with holding onto allocated byte arrays far beyond when they
> > were
> > >> > used.  The memory could only be freed via closing the IndexWriter.
> > >> >
> > >> > I'm a little unclear on exactly what's happening.  Are you noticing
> > >> memory
> > >> > spike and stay constant at that level or is it a gradual increase?
> >  Is it
> > >> > causing your application to error, (ie OutOfMemory exception, etc)?
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Christopher
> > >> >
> > >> > On Mon, Nov 28, 2011 at 5:59 PM, Trevor Watson <
> > >> > powersearchsoftware@gmail.com> wrote:
> > >> >
> > >> >> I'm attempting to use Lucene.Net v2.9.2.2 in a Visual Studio 2005
> > (.NET
> > >> >> 2.0) environment.  We had a piece of software that WAS working.
>  I'm
> > not
> > >> >> sure what has changed however, the following code results in a
> memory
> > >> leak
> > >> >> in the Lucene.Net component (or a failure to clean up used memory).
> > >> >>
> > >> >> The code in issue is here:
> > >> >>
> > >> >>  private void SaveFileToFileInfo(Lucene.Net.Index.IndexWriter
iw,
> > bool
> > >> >> delayCommit, string sDataPath)
> > >> >> {
> > >> >>   Document doc = getFileInfoDoc(sDataPath);
> > >> >>   Analyzer analyzer = clsLuceneFunctions.getAnalyzer();
> > >> >>   if (this.FileID == 0)
> > >> >>   {
> > >> >>      string s = "";
> > >> >>   }
> > >> >>   iw.UpdateDocument(new Lucene.Net.Index.Term("FileId",
> > >> >> this.fileID.ToString("000000000")), doc, analyzer);
> > >> >>
> > >> >>   analyzer = null;
> > >> >>   doc = null;
> > >> >>   if (!delayCommit)
> > >> >>                iw.Commit();
> > >> >> }
> > >> >>
> > >> >> Commenting out the line iw.UpdateDocument resulted in no memory
> > >> increase.
> > >> >> I also tried replacing it with a deleteDocument and  AddDocument
> and
> > the
> > >> >> memory increased the same as using the UpdateDocument function
> > >> >>
> > >> >> The getAnalyzer() function returns a ExtendedStandardAnalyzer,
but
> > it's
> > >> the
> > >> >> UpdateDocument line specifically that gives me the issue.
> > >> >>
> > >> >> Any assistance would be greatly appreciated.
> > >> >>
> > >> >> Trevor Watson
> > >> >>
> > >> >
> > >>
> > >
> >
>

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