Do not use this issue tracker to ask questions, instead use one of these channels. Questions will likely be closed without notice.
Version
Which version(s) did you encounter this bug ?
Vert.x 3.9.16
Context
I have an application that is using Vert.x 3.7.1 and I am trying to upgrade to the latest minor version Vert.x 3.9.16. It communicates with another application using Vert.x 3.9.14 using the SockJS event bridge. When upgrading the first application from Vert.x 3.7.1 to Vert.x 3.9.16, we notice an infinite number of logs of what appears to be reconnects.
I want to gain any insight with respect to websockets and how the connections are being handled with Vert.x since 3.7.1. Any information would be greatly appreciated to help me understand why I'm seeing this behavior. Thanks!
When we reboot the EC2 instance for both applications. Then the problem resolves, but that is not an ideal solution in Production.
Do you have a reproducer?
Unfortunately, not at the moment.
Link to github project/gist
N/A
Steps to reproduce
Application A has Vert.x 3.7.1
Application B has Vert.x 3.9.14
These applications are sending data amongst each other.
Upgrade Application A to Vert.x 3.9.16 and notice infinite number of logs of reconnects / websocket issues.
Extra
Anything that can be relevant such as OS version, JVM version
Questions
Do not use this issue tracker to ask questions, instead use one of these channels. Questions will likely be closed without notice.
Version
Which version(s) did you encounter this bug ? Vert.x 3.9.16
Context
I have an application that is using Vert.x 3.7.1 and I am trying to upgrade to the latest minor version Vert.x 3.9.16. It communicates with another application using Vert.x 3.9.14 using the SockJS event bridge. When upgrading the first application from Vert.x 3.7.1 to Vert.x 3.9.16, we notice an infinite number of logs of what appears to be reconnects.
I want to gain any insight with respect to websockets and how the connections are being handled with Vert.x since 3.7.1. Any information would be greatly appreciated to help me understand why I'm seeing this behavior. Thanks!
When we reboot the EC2 instance for both applications. Then the problem resolves, but that is not an ideal solution in Production.
Do you have a reproducer?
Unfortunately, not at the moment.
Steps to reproduce
Extra