Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
First mail executed from Vertx's ordered blocking pool gets stuck
See original GitHub issueDescribe the bug
My application is trying to send emails from a thread in vertx’s blocking pool with ordered=true. The first mail sent from the application get’s stuck/times out when I use the reactive mailer directly with .await.atMost(…). The email is still sent (I get it) after the exception is raised.
I suspect that something in the SMTP connection handshake requires ordered execution, too, and the threads deadlock.
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
Start this application in dev mode and then run curl localhost:8080/pooled?ordered=true -v -X POST. The request should complete with 204 but this appears in server log:
2022-10-03 14:10:09,101 INFO [com.exa.GreetingResource] (executor-thread-0) About to send mail through pool, ordered=true
2022-10-03 14:10:09,102 INFO [com.exa.GreetingResource] (vert.x-worker-thread-0) Sending mail...
2022-10-03 14:10:14,124 ERROR [com.exa.GreetingResource] (vert.x-worker-thread-0) Failed to send: io.smallrye.mutiny.TimeoutException
...
Note that the SMTP server used in this example requires you to execute it from within Red Hat internal network.
Output of uname -a or ver
No response
Output of java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.12.3, also 2.13.0
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
No response
Issue Analytics
- State:
- Created a year ago
- Comments:8 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Why do you use the reactive mailer on a vertx worker thread? I mean it would make sense to use the imperative/blocking version on a worker thread and the reactive version on the even loop (an I/O thread), i.e. in a non-blocking resource or scheduler method.
Could you please provide a simple project that would reproduce this behavior?
The problem comes from the usage of ordered
executeBlocking, which creates a Frankenstein monster in terms of the execution model (you are on an event loop, you switch to a worker, but you can’t go back to the event loop because ofordered=true) Either use the reactive mailer, and use Uni / Multi, or use the imperative mailer.