[
https://issues.apache.org/jira/browse/LUCENE-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-7237:
---------------------------------
Attachment: LUCENE-7237.patch
I gave it a try. The patch is large, but the change is quite simple, most line
changes are due to indentation since I replaced synchronized methods with calls
to Lock.(un)lock() in try/finally blocks. The interesting part is in
CachingWeightWrapper#scorer where we now do:
{code}
// Short-circuit: Check whether this segment is eligible for caching
// before we take a lock because of #get
if (shouldCache(context) == false) {
return in.scorer(context);
}
// If the lock is already busy, prefer using the uncached version than
waiting
if (lock.tryLock() == false) {
return in.scorer(context);
}
DocIdSet docIdSet;
try {
docIdSet = get(in.getQuery(), context);
} finally {
lock.unlock();
}
if (docIdSet == null) {
if (policy.shouldCache(in.getQuery(), context)) {
docIdSet = cache(context);
putIfAbsent(in.getQuery(), context, docIdSet);
} else {
return in.scorer(context);
}
}
assert docIdSet != null;
if (docIdSet == DocIdSet.EMPTY) {
return null;
}
final DocIdSetIterator disi = docIdSet.iterator();
if (disi == null) {
return null;
}
return new ConstantScoreScorer(this, 0f, disi);
{code}
Because of the {{tryLock()}} call, if the lock is already held because another
thread is using the cache, we just return a scorer produced by the original
weight rather than wait.
> LRUQueryCache should rather not cache than wait on a lock
> ---------------------------------------------------------
>
> Key: LUCENE-7237
> URL: https://issues.apache.org/jira/browse/LUCENE-7237
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-7237.patch
>
>
> This is an idea Robert just mentioned to me: currently the cache is using a
> lock to keep various data-structures in sync. It is a pity that you might
> have contention because of caching. So something we could do would be to not
> cache when the lock is already taken.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
