lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENENET-610) Reduce locking in FieldCacheImpl::Cache::Get
Date Sun, 29 Dec 2019 08:12:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004701#comment-17004701
] 

Shad Storhaug edited comment on LUCENENET-610 at 12/29/19 8:11 AM:
-------------------------------------------------------------------

We have replaced WeakDictionary with ConditionalWeakTable in Lucene.NET 4.8.0-beta00007, but
some of the APIs of ConditionalWeakTable that Lucene.NET requires are only available on .NET
Standard 2.1.

If you are using a platform that supports .NET Standard 2.1, could you please check out whether
this change resolves the issue you are experiencing?


was (Author: nightowl888):
We have replaced WeakDictionary with ConditionalWeakTable in Lucene.NET 4.8.0-beta00007, but
some of the APIs ConditionalWeakTable that Lucene.NET requires are only available on .NET
Standard 2.1.

If you are using a platform that supports .NET Standard 2.1, could you please check out whether
this change resolves the issue you are experiencing?

> Reduce locking in FieldCacheImpl::Cache::Get
> --------------------------------------------
>
>                 Key: LUCENENET-610
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-610
>             Project: Lucene.Net
>          Issue Type: Improvement
>          Components: Lucene.Net Core
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Thomas Mathew
>            Priority: Minor
>              Labels: up-for-grabs
>
> We noticed a lot of contention in FieldCacheImpl::Cache::Get (our queries use a lot
of query time joins + sorting, so we hit the field cache a lot).
> We use a SearcherManager with warm-up queries to populate the field cache so we would
expect it to be initialized in most cases before we hit it for actual requests.
> The implementation seems to lock even for the happy path (when everything's already initialized).
This seems like a by-product of the choice of data structures (the underlying WeakDictionary,
WeakHashMap etc are not threadsafe) and so the locking is required in case the dictionary
gets resized.
> Ideally we could be using thread-safe data structures and only lock when initializing
the data.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message