Skip to content

Ensure close is called under lock in the case of an engine failure#5800

Merged
s1monw merged 1 commit intoelastic:masterfrom
s1monw:close_enging_on_close
Apr 16, 2014
Merged

Ensure close is called under lock in the case of an engine failure#5800
s1monw merged 1 commit intoelastic:masterfrom
s1monw:close_enging_on_close

Conversation

@s1monw
Copy link
Copy Markdown
Contributor

@s1monw s1monw commented Apr 14, 2014

Until today we did close the engine without aqcuireing the write lock
since most calls were still holding a read lock. This commit removes
the code that holds on to the readlock when failing the engine which
means we can simply call #close()

@s1monw s1monw self-assigned this Apr 14, 2014
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Typo... should be assertLockIsHel_d_

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

LOL yeah :)

@bleskes
Copy link
Copy Markdown
Contributor

bleskes commented Apr 15, 2014

I like it! it makes things cleaner. Left some comments..

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

should we just catch Throwable here to be safe?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

also applies to other places in the code below, if we decide to do it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

well this is what the code used to do. I think we are find here as it is to be honest....

@s1monw
Copy link
Copy Markdown
Contributor Author

s1monw commented Apr 15, 2014

@bleskes @kimchy thanks guys I commented and pushed a new commit

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is an excess to the indexWriter without a lock. I think this can lead to an NPE if the shard is closed. I realize it's not part of the change, but I think we should deal with it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I will use a local version of the indexwriter here...

@s1monw
Copy link
Copy Markdown
Contributor Author

s1monw commented Apr 16, 2014

@bleskes thanks for the review - I pushed another commit

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think writer can be null if optimizeMutex is true when the method begins. It seems we have this recurrent pattern of calling ensureOpen and than getting the indexWriter to do something. Perhaps we can change ensureOpen to either throw an exception or to return a non-null writer (guaranteed) . This this can become ensureOpen().waitForMerges()

@bleskes
Copy link
Copy Markdown
Contributor

bleskes commented Apr 16, 2014

thx. Simon. Looking good. Left one last comment. I'm +1 on this otherwise.

@s1monw
Copy link
Copy Markdown
Contributor Author

s1monw commented Apr 16, 2014

I fixed your last suggestion! thanks for all the reveiws @bleskes I think it's ready, if you don't object I'd like to rebase and push it.

@bleskes
Copy link
Copy Markdown
Contributor

bleskes commented Apr 16, 2014

thx. ++1 :)

Until today we did close the engine without aqcuireing the write lock
since most calls were still holding a read lock. This commit removes
the code that holds on to the readlock when failing the engine which
means we can simply call #close()
@s1monw s1monw merged commit be14968 into elastic:master Apr 16, 2014
@s1monw s1monw deleted the close_enging_on_close branch April 16, 2014 13:36
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 v1.2.0 v2.0.0-beta1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants