-
Notifications
You must be signed in to change notification settings - Fork 910
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
Schedulers.isInNonBlockingThread() should return true on EventLoop #2404
Comments
This looks like it was a proguard issue up to 0.97.0. The But the issue should already be fixed at HEAD - now we use the so proguard keeps it. |
Ah, I couldn't even imagine that. Thanks! |
Thanks for the inspection! The mystery is solved. 🕵️♀️ |
Already Fixed by #2275 |
Related: line#2404 Motivation: We allowed Proguard to prune all classes that are not under `com.linecorp.armeria` (except the internal ones). This can make our own forked tag interface `reactor.core.scheduler.NonBlocking` to be pruned by ProGuard, although it is currently kept indirectly and automatically. It'll be safer if we configure ProGuard explicitly. Modifications: - Add ProGuard `keep` for `reactor.core.scheduler.NonBlocking` Result: - No chance of regression
Related: #2404 Motivation: We allowed Proguard to prune all classes that are not under `com.linecorp.armeria` (except the internal ones). This can make our own forked tag interface `reactor.core.scheduler.NonBlocking` to be pruned by ProGuard, although it is currently kept indirectly and automatically. It'll be safer if we configure ProGuard explicitly. Modifications: - Add ProGuard `keep` for `reactor.core.scheduler.NonBlocking` Result: - No chance of regression
Related: line#2404 Motivation: We allowed Proguard to prune all classes that are not under `com.linecorp.armeria` (except the internal ones). This can make our own forked tag interface `reactor.core.scheduler.NonBlocking` to be pruned by ProGuard, although it is currently kept indirectly and automatically. It'll be safer if we configure ProGuard explicitly. Modifications: - Add ProGuard `keep` for `reactor.core.scheduler.NonBlocking` Result: - No chance of regression
In #1665, we made our
EventLoop
implementNonBlocking
interface so that a user who uses Project Reactor gets a warning log when he/she is using a blocking call on ourEventLoop
s.We didn't use
NonBlocking
in Project Reactor, but added it under our ownreactor.core.scheduler
directory because we didn't want to add the Reactor dependency to the core.However, it doesn't seem to work so we should fix it.
Sample snippet from @joonhaeng:
The text was updated successfully, but these errors were encountered: