Replies: 3 comments 7 replies
-
|
Alright so I slept on it and enabled debugging: It seems that jetty is waiting for HTTP connections to close before shutdown. It happens twice in the log (1s for each connection so it explains my 2s delay). I added a cleanup method to close the HTTP client after each test and that solves the issue, the tests now run as fast as before. @AfterEach
void cleanup() {
this.client.close();
}Am I doing something wrong in my tests? I don't think I'm leaving open connections. Should the documentation be updated to include a cleanup method, or should |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Athou. The problem you describe is related to the handling of HTTP connections. As the Mozilla docs state, the default value for the Regarding the exception in the Jetty debug logs: The Jetty However, the much cleaner option for Dropwizard is to set this with a client property. Dropwizard 3.x and 4.x use the client.property(Apache5ClientProperties.REUSE_STRATEGY, (ConnectionReuseStrategy) (request, response, context) -> false);That being said, the behavior to keep connections alive is common practice and shouldn't be changes for the testing package IMHO. With this viable workaround, that should be fine. |
Beta Was this translation helpful? Give feedback.
-
|
We ran into a similar problem when trying to upgrade graphhopper/graphhopper#2920 from Dropwizard 2 to Dropwizard 3. Some of our tests were hanging indefinitely after the upgrade. We were able to reduce the problem to the following code (run within the Dropwizard repository on the release/4.0.x branch): package io.dropwizard.testing.junit5;
import io.dropwizard.core.Application;
import io.dropwizard.core.Configuration;
import io.dropwizard.core.setup.Environment;
import jakarta.ws.rs.POST;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.client.Entity;
import jakarta.ws.rs.core.Response;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
@ExtendWith(DropwizardExtensionsSupport.class)
public class DropwizardAppExtensionClientHangsTest {
@Path("/")
public static class MyResource {
@POST
public Response doPost() {
return Response.ok().build();
}
}
public static class MyApp extends Application<Configuration> {
@Override
public void run(Configuration configuration, Environment environment) throws Exception {
environment.jersey().register(new MyResource());
}
}
private static final DropwizardAppExtension<Configuration> app = new DropwizardAppExtension<>(MyApp.class, new Configuration());
@Test
public void myTest() {
for (int i = 0; i < 10; i++) {
post();
System.out.println("POST " + i + " complete");
}
}
private static void post() {
// send POST request against a missing endpoint (provoking 404)
Response response = app.client().target("http://localhost:8080/not_found").request().post(Entity.json("{}"));
System.out.println("status: " + response.getStatus());
}
}This test hangs after completing the first ~6 requests. The same happens on the release/3.0.x branch, but the release/2.0.x branch does not show this problem. Adding app.client().property(Apache5ClientProperties.REUSE_STRATEGY, (ConnectionReuseStrategy) (request, response, context) -> false);before sending the request in the |
Beta Was this translation helpful? Give feedback.
-
|
@joschi I don't think it's a good option to set the client property to fix this. I can't find an issue on the client-side. We don't use When using the |
Beta Was this translation helpful? Give feedback.
-
|
@otbutz When using the Jersey |
Beta Was this translation helpful? Give feedback.
-
|
@joschi do you have new information regarding this issue? I used the snippet from @easbar (with sometimes slightly different imports) and ran it against different releases using the command: The argumentation from @zUniQueX makes sense to me and so I thought this sounds like a server-side problem and would be an argument not to migrate yet. But from the linked changes I read the section "Modification of the client in |
Beta Was this translation helpful? Give feedback.
-
|
@joschi sorry to ping you again on this issue. It is tricky for us to decide from the outside if this is a client or server issue. Could you have a quick look or was this already fixed in a more recent version? |
Beta Was this translation helpful? Give feedback.
-
|
I tried v3.0.0-beta.3 but used the dependencies of v3.0.0-beta.4 and the test does not hang. There is also no problem when I switch to this commit right before the httpClient change. But the test hangs with this commit that switches to httpClient 5. So, this together points more to a client issue IMO or what do other think of this? Let's assume this is a client issue shouldn't it be avoided with e.g. a client config change in DropwizardAppExtension.java? |
Beta Was this translation helpful? Give feedback.
-
Hey there,
I've been using dropwizard for CommaFeed for almost 10 years now, thank you for the great work, it's been a joy to work with! 😃
I updated to 4.0.5 from 2.1.6 and everything works fine. However, I just noticed that the integration tests take a lot more time now, there's a ~2s delay between tests during server shutdown that was not happening before:
The regression is noticeable since this commit Athou/commafeed@fd0e542
The delay does not seem to happen when the app is shutdown when running normally, it only seem to happen when tests annotated with
@ExtendWith(DropwizardExtensionsSupport.class)are running.Is this something you noticed too? Do you have any pointers as to where to look or why this is happening?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions