While debugging a problem where 400 threads were waiting for a single lock we
traced the issue to the getUnInvertedField method.
public static UnInvertedField getUnInvertedField(String field,
SolrIndexSearcher searcher) throws IOException {
SolrCache<String,UnInvertedField> cache = searcher.getFieldValueCache();
if (cache == null) {
return new UnInvertedField(field, searcher);
}
UnInvertedField uif = null;
Boolean doWait = false;
synchronized (cache) {
uif = cache.get(field);
if (uif == null) {
cache.put(field, uifPlaceholder); // This thread will load this
field, don't let other threads try.
} else {
if (uif.isPlaceholder == false) {
return uif;
}
doWait = true; // Someone else has put the place holder in, wait for
that to complete.
}
}
while (doWait) {
try {
synchronized (cache) {
uif = cache.get(field); // Should at least return the placeholder,
NPE if not is OK.
if (uif.isPlaceholder == false) { // OK, another thread put this
in the cache we should be good.
return uif;
}
* cache.wait();*
}
} catch (InterruptedException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
"Thread interrupted in getUninvertedField.");
}
}
uif = new UnInvertedField(field, searcher);
synchronized (cache) {
cache.put(field, uif); // Note, this cleverly replaces the
placeholder.
*cache.notifyAll();*
}
return uif;
}
It seems that the code is waiting on the same object it is synchronized on,
thus the notifyAll call may never happen since is requires re-obtaining the
lock...
Am i missing something here? or is this a real bug?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Suspicious-Object-wait-in-UnInvertedField-getUnInvertedField-tp4128555.html
Sent from the Solr - User mailing list archive at Nabble.com.
