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.