Skip to content
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

JdkConnector does not properly cleanup ERROR state connections #5599

Open
dude-abides opened this issue Apr 10, 2024 · 3 comments
Open

JdkConnector does not properly cleanup ERROR state connections #5599

dude-abides opened this issue Apr 10, 2024 · 3 comments

Comments

@dude-abides
Copy link

dude-abides commented Apr 10, 2024

I am using Dropwizard 4 (Jersey 3.0.5) on Java 17. This problem exists in 3.0.12 as well.

When an HttpConnection transitions to ERROR from IDLE state, the connection gets closed but not removed from DestinationConnectionPool. This results in the next request failing regardless of whether the server has been restarted.

My guess is that cleanClosedConnection should be called at:

@senivam
Copy link
Contributor

senivam commented Apr 25, 2024

@dude-abides which is the request or how do you receive the ERROR state after which a connection is not removed?

@dude-abides
Copy link
Author

Step to recreate

  1. Run a server and client on the same machine
  2. Make one request to server successfully
  3. Shutdown the server (forced)
  4. Make another request to the server

@senivam
Copy link
Contributor

senivam commented Apr 26, 2024

So, I've retried the described behavior.
The main difference I've got is:
When the server is being shut down between requests, the request that goes to nowhere results in the ERROR state but in the DestinationConnectionPool it hits the

case CONNECTING: {
                            removeAllPendingWithError(connection.getError());
                            return;
                        }

case because the oldState is CONNECTING thus the removeAllPendingWithError(connection.getError()); properly cleans all connections and the next request which runs to the already started server passes OK. Furthermore, the line in the DestinationConnectionPool you are referring to handles unexpected behavior by throwing the IllegalStateException("Illegal state transition, old state: " + oldState + " new state: " + newState); exception which terminates all connections in the flow instantly. I'm not sure, how it's possible to bypass the CONNECTING state from the IDLE. All my investigations resulted in the flow that defines the IDLE state as the primary and then in case of sending the request the flow goes to the CONNECTING state. If you have some special use case that somehow manages to violate this sequence please share it I'll try to make it impossible :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants