lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pablo Saavedra" <>
Subject Re: LUCENE-831 (complete cache overhaul) -> mem use
Date Fri, 14 Nov 2008 18:00:43 GMT
I have the same problem with cache and too many sorted fields, and had to
implement a big workaround to be able to plug my own cache implementation in
lucene 2.3.2. What I'd really like to see in the new cache implementation is
easier pluggability and extension of the lucene classes, which is currently
not possible due to visibility issues.

My 2 cents.

2008/11/14 Britske <>

> Hi,
> I recently saw activity on LUCENE-831 (Complete overhaul of FieldCache
> API/Implementation) which I have interest in.
> I posted previously on this with my concern that given the current default
> cache I sometimes get OOM-errors because I have a lot of fields which are
> sorted on, which ultimately causes the fieldcache to grow greater then
> available RAM.
> ultimately I want to subclass the new pluggable Fieldcache of lucene-831 to
> offload to disk (using ehcache or memcachedB or something) but havn't found
> the time yet.
> What I would like to know for now is if perhaps the newly implemented
> standard cache in LUCENE-831 uses another strategy of caching than the
> standard Fieldcache in Lucene.
> i.e: The normal cache consumes memory while generating a fieldcache for
> every document in lucene even though the document hasn't got that field
> set.
> Since my documents are very sparse in these fields I want to sort on it
> would differ a_lot when documents that don't have the field in question set
> don't add up in the used memory.
> So am I lucky? Or would I indeed have to cook up something myself?
> Thanks and best regards,
> Geert-Jan
> --
> View this message in context:
> Sent from the Lucene - Java Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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