quarkus: Mutiny Vertx NetClient Request/Reply Pipeline Bug

Describe the bug

While using Mutiny With Vertx Netclient (Tcp Client) to write and read tcp messages, read gets stuck after receiving the first message.

Expected behavior

Reading of tcp messages should not block the mutiny based netclient pipeline. (This uses netclient tcp client)

Actual behavior

Reading of tcp messages should not block the mutiny based netclient pipeline. This makes mutiny unsable for tcp communication which is a bummer. Vertx Core Apis (using get delegate) work fine.

How to Reproduce?

QuarkusMutinyTcpNetClientSendAndReceiveBug.zip There would be two projects in attached zip. One for Mutiny based Tcp Client and another for mock server which is used to echo messages.

Both are maven projects. Import them and run the server project first and then the tcp client.

Output of uname -a or ver

No response

Output of java -version

11

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.2.1.FINAL

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

This is one of the most basic features that is going to be used by users (Tcp based comm) . It would be great if we can fix this asap. I have limited knowledge on vertx but would love to contribute. But let me know if i can learn and contribute in any way.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 25 (11 by maintainers)

Most upvoted comments

Thanks for the sample. Appreciate it. Yes in my usecase only one connection has to be maintained and we do that with core vertx APIs. I agree with such lower stuff core vertx APIs are a better choice. It was just that I wanted to avoid writing code for delaying the item and handling failures etc as that is handled v well by mutiny. But this is good learning. Thankyou

my bad. This is off topic but i did not realize you are the author of the vertx in action. Planning to read that thanks for the book 😃 cheers