kill ThreadInterruptedException [LUCENE-4649]
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
the way we currently do this is bogus.
For example in FSDirectory's fsync, i think we should instead:
```
} catch (InterruptedException ie) {
- throw new ThreadInterruptedException(ie);
+ Thread.currentThread().interrupt(); // restore status
+ IOException e = new java.io.InterruptedIOException("fsync() interrupted");
+ e.initCause(ie);
+ throw e;
```
and crazy code in IndexWriter etc that catches ThreadInterruptedExc just to restore status should be removed.
Instead the guy doing the catch (InterruptedException) should do the right thing.
---
Migrated from [LUCENE-4649](https://issues.apache.org/jira/browse/LUCENE-4649) by Robert Muir (@rmuir), updated Jan 02 2013
Attachments: [LUCENE-4649_broken.patch](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-4649/LUCENE-4649_broken.patch), [LUCENE-4649.patch](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-4649/LUCENE-4649.patch)
Contributor guide
Research direction
Start with the attached LUCENE-4649 patches and inspect FSDirectory's fsync handling and the ThreadInterruptedException catches in IndexWriter. Trace each InterruptedException path before changing it. Done means interruption status is restored at the original catch sites, InterruptedIOException is used where described, and redundant ThreadInterruptedException handling is removed without leaving missed call sites.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- search
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100