Hi Kristian,
It sounds like something outside of the test resource+method shown is
blocking the requests. Maybe the filter itself? What does the bootstrap
config (YAML) look like--perhaps some nonstandard options appeared while
grappling with inherently slow requests?
Is this running on a "normal" server and JVM?
Although orthogonal to the stated problem, you might find ChunkedOutput
useful:
import org.glassfish.jersey.server.ChunkedOutput;
@RolesAllowed("admin")
@GET
@Path("slow")
public ChunkedOutput<String> slowchunk(
@QueryParam("count") @DefaultValue("3") int count) throws IOException {
final ChunkedOutput<String> output = new ChunkedOutput<>(String.class);
output.write("begin\n");
new Thread() {
@Override
public void run() {
for (int i = 0; i < count; i++) {
try {
Thread.sleep(1500);
output.write("chunk " + i + "\n");
} catch (IOException e) {
logger.info(null, e);
break;
} catch (InterruptedException e) {
logger.info("interrupted");
}
}
try {
output.close();
} catch (IOException e) {
logger.info(null, e);
}
}
}.start();
return output;
}
On Thursday, July 20, 2017 at 4:31:12 PM UTC-4, Kristian Rink wrote:
>
> Steve; thanks a bunch for your feedback. Well we're so far looking into
> getting the backend queries to perform faster so to get from 45s down
> to somewhere < 10s, but we will see how this works.
>
> However, in order to track it down, we did some "low-level" (?)
> experiments: Simple dummy resource exposing a single method (see below)
> that waits before returning a result, and then we fired two requests
> more or less simultaneously (curl in two different terminal windows) at
> the server.
>
> Expectation would have been that all these requests take a while but
> then see responses more or less the same time.
>
> Actual behaviour is that the request 2 takes "twice" as long as the
> request 1 to finish, which looks like request 2 actually is processed
> only after request 1 finished. Logfile entries for these requests seem
> to prove that.
>
>
> I feel a bit dump for asking this but so far our expectations in Java
> servlet environments was that there's a thread created (or taken from a
> pool) to process each request. The behaviour we see here is somewhat
> different.
>
> Do we get something completely wrong here about how these things should
> work? Is there anything fundamental we miss here? We also played with
> acceptorThreads and selectorThreads and various configuration aspects
> in dropwizard but that doesn't seem to change anything....
>
> TIA and all the best,
> Kristian
>
>
>
> @Path("/dummy")
> @Api(value = "dummy")
> public class DummyResource {
>
> public DummyResource() {
> }
>
> @GET
> @Path("")
> @Produces(MediaType.APPLICATION_JSON)
> @ApiOperation(value = "dummy")
> @ApiResponses({@ApiResponse(code = 200, message = "dummy")})
> public String dummy() {
> try {
> Thread.sleep(10000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> return "dummy";
> }
>
> }
>
--
You received this message because you are subscribed to the Google Groups
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
