Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read segment info from latest commit whenever possible #11361

Merged

Conversation

dakrone
Copy link
Member

@dakrone dakrone commented May 26, 2015

Instead of listing the directory to file the latest segments_N file, we
should re-use the generation/filename from the last commit. This allows
us to avoid potential race conditions on the filesystem as well as
reduce the number of directory listings performed.

@dakrone
Copy link
Member Author

dakrone commented May 26, 2015

@mikemccand can you take a look at this?

@@ -152,7 +152,7 @@ public SegmentInfos readLastCommittedSegmentsInfo() throws IOException {
*/
private static SegmentInfos readSegmentsInfo(IndexCommit commit, Directory directory) throws IOException {
try {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe remove Directory directory arg here? Or assert that directory == commit.getDirectory()?

@mikemccand
Copy link
Contributor

LGTM, thanks @dakrone!

@dakrone dakrone force-pushed the read-si-from-searcher-commit-on-start branch from 41c9a61 to 6646881 Compare May 26, 2015 23:05
Instead of listing the directory to file the latest segments_N file, we
should re-use the generation/filename from the last commit. This allows
us to avoid potential race conditions on the filesystem as well as
reduce the number of directory listings performed.
@dakrone dakrone merged commit 6646881 into elastic:master May 26, 2015
@kevinkluge kevinkluge removed the review label May 26, 2015
@dakrone dakrone removed the v1.6.0 label May 27, 2015
@dakrone
Copy link
Member Author

dakrone commented May 27, 2015

I don't think I'm going to backport this, the Lucene API is different and I think I will work on an alternative to avoid upgrading Lucene 3.x segments when not needed, which is when the race condition usually occurs.

dakrone added a commit to dakrone/elasticsearch that referenced this pull request May 28, 2015
fails

In the event that reading from the latest commit fails, we should fall
back to reading from the `Store` using the traditional
`Directory.listAll()`

Related to elastic#11361
dakrone added a commit to dakrone/elasticsearch that referenced this pull request May 28, 2015
fails

In the event that reading from the latest commit fails, we should fall
back to reading from the `Store` using the traditional
`Directory.listAll()`

Related to elastic#11361
dakrone added a commit to dakrone/elasticsearch that referenced this pull request May 28, 2015
fails

In the event that reading from the latest commit fails, we should fall
back to reading from the `Store` using the traditional
`Directory.listAll()`

Related to elastic#11361
@dakrone dakrone deleted the read-si-from-searcher-commit-on-start branch June 1, 2015 22:34
@clintongormley clintongormley added >enhancement :Distributed/Store Issues around managing unopened Lucene indices. If it touches Store.java, this is a likely label. labels Jun 8, 2015
@clintongormley clintongormley changed the title [CORE] Read segment info from latest commit whenever possible Read segment info from latest commit whenever possible Jun 8, 2015
@clintongormley clintongormley added :Distributed/Engine Anything around managing Lucene and the Translog in an open shard. and removed :Distributed/Store Issues around managing unopened Lucene indices. If it touches Store.java, this is a likely label. labels Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Engine Anything around managing Lucene and the Translog in an open shard. >enhancement v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants