On 11/8/2016 4:27 PM, Yonik Seeley wrote: > So no, you should not expect to see an immediate return with > waitSearcher=false since it only represents the > open-and-register-searcher part.
That's too bad. I already have the SolrJ call happening in a separate thread, so it doesn't really affect my *current* program much. For a future version of the program, I have a question: If I have a SolrJ optimize running in a background thread, can I call close() on SolrClient and HttpClient objects (and remove all references to them) while that's happening and have all the objects properly turn into garbage, possibly at a later time when the optimize finishes? The 40+ seconds for the optimizes I have mentioned is the hot shard. I've seen optimizes on a cold shard take well over an hour. Basically, I want to be able to have my program dismantle all the objects (threads, SolrClient, HttpClient, JDBC, etc) related to building an individual index, reload its configuration, and set everything back up again, without stopping the program. Currently I do that by restarting the program entirely, but I want something much more dynamic, with a web interface to control it. I'd like it to be able to do this even when a LONG background optimize is happening. I do have a possible alternate plan: Use a client with a very short socket timeout for optimizes and ignore the exception. I'm worried that I won't be able to tell the difference between a problem with the optimize call and the socket timeout being reached. Thanks, Shawn
