Allow ActionListener to be called on the network thread #10573
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| return null; | ||
| } | ||
| return sync.getValue(); | ||
| } |
There was a problem hiding this comment.
Returning null feels wrong to me as then there is no difference between tryGet if the computation is not done and if it actually returns null. Maybe we need different semantics such as throwing an exception instead of returning null is sync.isDone() returns false?
There was a problem hiding this comment.
yeah, I considered a couple of approaches:
- The one above (overloading the
nullvalue to indicate not done). - Having a special case for doing get with timeout set to 0 where we don't assert on a networking thread.
- Having a method like you suggest called something like
getExpectingDonewhich is expected to be call only after the future is guaranteed to be done. If feeltryGetsounds like something very light where the expectation is that is not done (i.e., a syntactic sugar for if (isDone) get() ).
I don't like any of the above much, but I had a slight preference to the first. If you like the second better, I can do that. Of course, new ideas are welcome :)
There was a problem hiding this comment.
I had not though about option 2 but I really like the fact that it does not require to add a new API.
But if this argument does not resonate to you, feel free to push the change as-in, I don't have too strong feelings about it.
clintongormley
changed the title
To protect ourselves against running blocking operations on a network thread we have added an assertion that triggers that verifies that the thread calling a BaseFuture.get() is not a networking one. While this assert is good, it wrongly triggers when the get() is called in order to pass it's result to a listener of AbstractListenableActionFuture who is marked to run on the same thread as the callee. At that point, we know that the operation has been completed and the get() call will not block. To solve this, we add a tryGet() option which is guaranteed not to block. Relates to elastic#10402
bleskes
force-pushed
the
listener_future_network_thread
branch
from
1056ec8
to
1470cfe
Compare
|
@jpountz I applied your feedback and rebased. Can you have another look? |
|
LGTM |
bleskes
added a commit
that referenced
this pull request
Jun 4, 2015
To protect ourselves against running blocking operations on a network thread we have added an assertion that triggers that verifies that the thread calling a BaseFuture.get() is not a networking one. While this assert is good, it wrongly triggers when the get() is called in order to pass it's result to a listener of AbstractListenableActionFuture who is marked to run on the same thread as the callee. At that point, we know that the operation has been completed and the get() call will not block. To solve this, we change the assertion to ignore a get with a timeout of 0 and use that AbstractListenableActionFuture Relates to #10402 Closes #10573
bleskes
added a commit
that referenced
this pull request
Jun 4, 2015
To protect ourselves against running blocking operations on a network thread we have added an assertion that triggers that verifies that the thread calling a BaseFuture.get() is not a networking one. While this assert is good, it wrongly triggers when the get() is called in order to pass it's result to a listener of AbstractListenableActionFuture who is marked to run on the same thread as the callee. At that point, we know that the operation has been completed and the get() call will not block. To solve this, we change the assertion to ignore a get with a timeout of 0 and use that AbstractListenableActionFuture Relates to #10402 Closes #10573
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To protect ourselves against running blocking operations on a network thread we have added an assertion that triggers that verifies that the thread calling a BaseFuture.get() is not a networking one. While this assert is good, it wrongly triggers when the get() is called in order to pass it's result to a listener of AbstractListenableActionFuture who is marked to run on the same thread as the callee. At that point, we know that the operation has been completed and the get() call will not block.
To solve this, we change the assertion to ignore a get with a timeout of 0 and use that AbstractListenableActionFuture
Relates to #10402