On Tue, Oct 2, 2012 at 11:48 AM, Robert Krüger <krue...@lesspain.de> wrote: > Hi, > > I'm using Solr 3.6.1 in an application embedded directly, i.e. via > EmbeddedSolrServer, not over an HTTP connection, which works > perfectly. Our application uses Thread.interrupt() for canceling > long-running tasks (e.g. through Future.cancel). A while (and a few > Solr versions) back a colleague of mine implemented a workaround > because he said that Solr didn't handle the thread's interrupted > status correctly, i.e. not setting the interrupted status after having > caught an InterruptedException or rethrowing it, thus killing the > information that an interrupt has been requested, which breaks > libraries relying on that. However, I did not find anything up-to-date > in mailing list or forum archives on the web. Is that still or was it > ever the case? What does one have to watch out for when interrupting a > thread that is doing anything within Solr/Lucene? > > Any advice would be appreciated. > > Regards, > > Robert
Just in case anyone else has the same question: You cannot. Thread interruption is not handled properly so you should not use Solr in code that you plan to interrupt via Thread.interrupt. You will get stuff like IOExceptions so you cannot cleanly tell the difference between "real" errors and stuff caused by interruption. Reading old Jira issues, it looks as if this was a conscious decision because of the amount of work it would cause in API design changes and lots of checked exceptions the caller would have to handle.
