SOLR-16866: Reorder nested directory deletions to avoid NoSuchFileException#2349
Conversation
| public boolean closeCacheValueCalled = false; | ||
| public boolean doneWithDir = false; | ||
| private boolean deleteAfterCoreClose = false; | ||
| public Set<CacheValue> removeEntries = new HashSet<>(); |
There was a problem hiding this comment.
It's nice to see one less data structure to track
| CacheValue[] ret = vals.toArray(new CacheValue[0]); | ||
| Arrays.sort(ret, (a, b) -> b.path.compareTo(a.path)); | ||
| return Arrays.asList(ret); |
There was a problem hiding this comment.
minor: this would be nicer as a single statement using Java streams
HoustonPutman
left a comment
HoustonPutman
left a comment
There was a problem hiding this comment.
I have to say this is confusing stuff, but it certainly looks like an improvement
|
|
||
| @Test | ||
| public void reorderingTest() throws Exception { | ||
| // failure: 58F920FAAE5904EF |
There was a problem hiding this comment.
Are you still seeing a failure with this seed?
There was a problem hiding this comment.
ah, good catch. I think that crept in during development, and I neglected to remove it once the underlying issue was fixed. Definitely not failing for that seed anymore; removed that comment with dbc84ce
|
Assuming we want to wait until after 9.6 for this? It should be safe, but it's really only about reducing log noise, so is pretty low priority. |
|
I've seen this cause failures when moving replicas around, so I would love to see it fixed in 9.6 |
…LR-16866-deferred-directory-removal
…ous NoSuchFileException (apache#2349)
3 participants
https://issues.apache.org/jira/browse/SOLR-16866
alternative to #2336