-
Notifications
You must be signed in to change notification settings - Fork 926
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
Return a CompletableFuture from API methods that checks whether… #2275
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2275 +/- ##
============================================
- Coverage 73.67% 73.65% -0.02%
- Complexity 10168 10172 +4
============================================
Files 882 883 +1
Lines 38869 38891 +22
Branches 4813 4815 +2
============================================
+ Hits 28637 28646 +9
- Misses 7777 7790 +13
Partials 2455 2455
Continue to review full report at Codecov.
|
Maybe a user can just use BlockHound? https://github.com/reactor/BlockHound |
BlockHound seems cool and could be a best practice when running an Armeria app to catch other things like JDBC. But I think registering an agent is tedious enough that it could still be worth having something out of the box. The cost / performance of manually instrumenting these three common methods seems pretty good to me. What do you think? |
@trustin Any more thoughts on this? I notice there could be JDK version issues in the future with BlockHound - reactor/BlockHound#33. It's a very cool tool, but agents are so complex I think this is could be a small but effective improvement. |
Sorry. Let me check soon. Didn't have a chance to check the code yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good all in all.
...rc/main/java/com/linecorp/armeria/internal/eventloop/EventLoopCheckingCompletableFuture.java
Outdated
Show resolved
Hide resolved
core/src/main/java/com/linecorp/armeria/internal/eventloop/EventLoopThread.java
Outdated
Show resolved
Hide resolved
...est/java/com/linecorp/armeria/internal/eventloop/EventLoopCheckingCompletableFutureTest.java
Outdated
Show resolved
Hide resolved
…ing methods are called from an event loop.
1120dc7
to
aca8796
Compare
I have switched to |
Hmm test doesn't seem to work well on Windows. Happen to have any ideas why that could be? |
Maybe |
Doh duh... thanks for finding it! |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks nice. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have left a humble opinion but mostly LGTM. Thanks a lot!
return; | ||
} | ||
final Thread thread = Thread.currentThread(); | ||
if (thread instanceof NonBlocking && REPORTED_THREADS.add(thread)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC this NonBlocking
interface is created in the project reactor.
It seems an edge case but a non-eventloop thread might pass this condition and log this message. I am wondering if it is acceptable. Unless I suggest changing EventLoopCheckingCompletableFuture
to NonBlockCheckingCompletableFuture
and related message. 😀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Armeria EventLoopThread
implements Nonblocking
. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally checked instanceof EventLoopThread
but changed to NonBlocking
I think to avoid moving a package-local EventLoopThread
to public in internal
package. @trustin Any thoughts? I lean towards it being small enough not to worry about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that :-) Just worried other non-event loop thread could implement NonBlocking
.
But it seems too many worries. 😜
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can warn that as well because a thread which implements NonBlocking
is doing blocking operation. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah then it makes sense. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So do we need to update the WARN log message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not completely sure it is worth to update the message.
If we do, then leave the original sentence and put extra information just in case. 😀
- Calling a blocking method on CompletableFuture from an event loop thread.
+ Calling a blocking method on CompletableFuture from an event loop thread or non-blocking thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anuraaga Could you update the log message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
…e#2275) … blocking methods are called from an event loop or a non-blocking thread. We have heard many stories of bad experiences because of blocking the event loop in an armeria server request. While we wouldn't be able to check all cases of this (e.g., calling JDBC from an event loop), it's fairly simple to check this for futures returned by Armeria methods and I think this covers a lot of cases. This changes to return a special implementation of `CompletableFuture` that logs from blocking methods with a stack trace.
… blocking methods are called from an event loop or a non-blocking thread.
We have heard many stories of bad experiences because of blocking the event loop in an armeria server request. While we wouldn't be able to check all cases of this (e.g., calling JDBC from an event loop), it's fairly simple to check this for futures returned by Armeria methods and I think this covers a lot of cases. This changes to return a special implementation of
CompletableFuture
that logs from blocking methods with a stack trace.Let me know any general feedback and then I'll apply to other methods (though I guess
aggregate()
is the most common way to get a future from Armeria).