lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Bowyer (JIRA)" <>
Subject [jira] [Commented] (SOLR-3514) WeakHashMap in FileFloatSource's cache only cleaned by GC
Date Wed, 06 Jun 2012 23:39:23 GMT


Greg Bowyer commented on SOLR-3514:

One thing I will add to this, although I dont reject the idea of better cache management is
that there are issues with reference processing in some JVMS relating to some configurations
of GC's

This was fixed for release in 1.7.0_04 here

Essentially the fix means that references are not traced as part of normal marking, only during
big bad stop the world GC's

> WeakHashMap in FileFloatSource's cache only cleaned by GC
> ---------------------------------------------------------
>                 Key: SOLR-3514
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: search
>    Affects Versions: 3.6, 4.0
>            Reporter: Gregg Donovan
>            Priority: Minor
>              Labels: patch
>         Attachments: SOLR-3514.patch
> We've encountered GC spikes at Etsy after adding new ExternalFileFields a decent number
of times. I was always a little confused by this behavior -- isn't it just one big float[]?
why does that cause problems for the GC? -- but looking at the FileFloatSource code a little
more carefully, I wonder if this is due to using a WeakHashMap that is only cleaned by GC
or manual invocation of a
> request handler.
> FileFloatSource stores a WeakHashMap keyed by {{IndexReader}}. In the [code|],
it mentions that the implementation is modeled after FieldCache. However, the FieldCacheImpl
[adds listeners for IndexReader close events and uses those to purge its caches|].
Should we be doing the same in FileFloatSource?
> Attached is a mostly untested patch with a possible implementation. There are probably
better ways to do it (e.g. I don't love using another WeakHashMap), but I found it tough to
hook into the IndexReader lifecycle without a) relying on classes other than FileFloatSource
b) changing the public API of FIleFloatSource or c) changing the implementation too much.
> There is a RequestHandler inside of FileFloatSource -- [ReloadCacheRequestHandler|]
-- that can be used to clear the cache
> entirely, but this is sub-optimal for us for a few reasons:
> * It clears the entire cache. ExternalFileFields often take some
> non-trivial time to load and we prefer to do so during SolrCore
> warmups. Clearing the entire cache while serving traffic would likely
> cause user-facing requests to timeout.
> * It forces an extra commit with its consequent cache cycling, etc..

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message