Since the new multiThreaded search feature landed, I see a new test failure involving "RejectedExecutionException" being thrown: https://ge.apache.org/s/5ack462ji4mlu/tests/task/:solr:core:test/details/org.apache.solr.search.TestRealTimeGet/testStressGetRealtime?top-execution=1 It is thrown at a low level in Lucene building TermStates concurrently. I doubt the problem is specific to that test (TestRealTimeGet) but that test might induce more activity than most tests, thus crossing some thresholds like the queue size -- apparently 1000.
** I don't think we should be throwing a RejectedExecutionException when running a Search query **. Have others explored this topic further and have ideas to share, even including ruled out ideas? Ishan, Noble, ? I'd prefer to avoid catching this exception to take some other action -- would feel too much like a hack. I'm optimistic a more elegant solution without doing this can be found. Perhaps SynchronousQueue? Maybe I can rule this out based on a little test I did, as it throws a RejectedExecutionException (instead of blocking), which I'd rather not catch. Perhaps a LinkedBlockingQueue (thus infinite queue size) but have an ExecutorService subclass that observes the queue size to see if a threshold is reached and if so then runs the task directly? This way we never reject and the caller threads receive back pressure by doing the work that they would have done anyway with multiThreaded=false ! There is plenty of precedent for an ExecutorService that runs the task in the caller thread -- I'm thinking of Lucene's SameThreadExecutorService and Solr's SimpleFacets.directExecutor. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
