Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of peterlkeegan@gmail.com
 designates 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=XWNLeVbUghpFa8Aer1iQIiPNBqzx1loC5muA9CMjCU7b8UUAiEvzxCtTGFtN1vDuOaSMiFQ+wD30gzn1zEu/JCKoX1ur6VlFx5xhlZx8wGFr9tMLozP8fgsIuM4Mu0lHOx2tX3iL3oCg4v844Xs3C0wAPGWkhhX1XlG7gjodTBE=
Message-ID: <e994873a0802190637w2ddb6237p8f134577bcd8e7cb@mail.gmail.com>
Date: Tue, 19 Feb 2008 09:37:05 -0500
From: "Peter Keegan" <peterlkeegan@gmail.com>
To: java-user@lucene.apache.org
Subject: Re: FieldSortedHitQueue rise in memory
In-Reply-To: <a2c7a60e0802181320o5402f4heb3c9cf6ae578060@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11618_16560090.1203431825665"
References: <a2c7a60e0802181320o5402f4heb3c9cf6ae578060@mail.gmail.com>

------=_Part_11618_16560090.1203431825665
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Brian,

I ran into something similar a long time ago. My custom sort objects were
being cached by Lucene, but there were too many of them because each one had
different 'reference values' for different queries. So, I changed the equals
and hashcode methods to NOT use any instance data, thus avoiding the
caching.

Could this be what you're seeing?

Peter


On Feb 18, 2008 4:20 PM, Brian Doyle <brianpdoyle@gmail.com> wrote:

> We've implemented a custom sort class and use it to sort by distance.   We
> have implemented the equals and hashcode in the sort comparator.   After
> running for a few hours we're reaching peak memory usage and eventually
> the
> server runs out of memory.   We did some profiling and noticed that a
> large
> chunk of memory is being used in the
> lucence.search.FieldSortedHitQueueclass.   Has anyone seen this
> behavior before or know how we can stop this
> class from growing in size?
>

------=_Part_11618_16560090.1203431825665--