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

Pass through all exceptions in IndicesLifecycleListeners #9330

Merged
merged 1 commit into from Jan 19, 2015

Conversation

dakrone
Copy link
Member

@dakrone dakrone commented Jan 16, 2015

This allows a plugin or user that registers a listener to be able to
stop actions like creating an index or starting a shard by throwing an
exception. Previously all exceptions were logged without being rethrown.

@bleskes
Copy link
Contributor

bleskes commented Jan 16, 2015

I wonder if we should only rethrow exceptions of a certain exception type(s). I think the original idea was to protect against exceptions in listener code from causing an unneeded engine failure. Maybe we can even add this as a throws clause to the interface and document it as an official way to block index creation. Not sure, but I think it's worth considering. @dakrone what is your opinion?

@dakrone
Copy link
Member Author

dakrone commented Jan 16, 2015

@bleskes yeah I talked to @kimchy about that and we both agreed passing all exceptions seemed better.

Passing all exceptions through I think is cleaner in that there isn't a hidden element of a certain type of exception. Additionally listeners should handle exceptions themselves with a try-catch rather than bubbling them up so that they have to consider the failure case (ie, if this listener fails, do I really want to fail the shard)

@kimchy did you have any other reasons for preferring the re-throw versus certain exception type solution?

try {
client().admin().indices().prepareCreate("failed").setSettings(SETTING_NUMBER_OF_SHARDS, 1, "index.fail", true).get();
fail("should have thrown an exception");
} catch (Exception e) {
Copy link
Member

Choose a reason for hiding this comment

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

catch ElasticsearchException instead?

@javanna
Copy link
Member

javanna commented Jan 19, 2015

left a super minor comment, LGTM although I am not super sure about potential side effects that this change might have (not too familiar with this part of es)

@kimchy
Copy link
Member

kimchy commented Jan 19, 2015

@dakrone yea, you and me are on the same page. Its very easy to comprehend when you are implementing the listener, and it becomes the responsibility of the listener to catch exceptions/failures that should not cause the failure to bubble up

This allows a plugin or user that registers a listener to be able to
stop actions like creating an index or starting a shard by throwing an
exception. Previously all exceptions were logged without being rethrown.
@dakrone dakrone merged commit 283a467 into elastic:master Jan 19, 2015
@dakrone dakrone deleted the fail-engine-from-listener branch April 6, 2015 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants