apache / apache/lucene

kill ThreadInterruptedException [LUCENE-4649]

Open
#5,714 14 comments 0 reactions 0 assignees View on GitHub
legacy-jira-priority:Major type:bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.