Hi Thomas, You alluded to needing to debug further and my question would be if you have any calls to external services that aren't wrapped in a Future construct? (Blanking on the Java equivalent at the moment) I had a Scala app using Dropwizard that had the same issue and it turned out to be my calls to the backend data store blocking the thread. Wrapping that in a Future allowed the thread pool to free up that thread while the data store operation was being executed.
The Servlet context may be held and executed by a separate thread but if an operation within that thread blocks I believe it will still hamper your server's ability to handle more requests. Hope this helps at least your debugging efforts :) On Thursday, June 9, 2016 at 4:19:05 AM UTC-4, Thomas wrote: > > Hello, > > while load testing of my server with jmeter(100 threads, ramp-up period 0) > I'll get 1% failures with connections timeouts. I set 20000 millis for > connection 60000 millis for response. More than enough to process a simple > request. It looks like, if all threads are busy then dropwizard stops > accepting new connections. > > However, all servlets use async context and all processing is done in > non-blocking manner. So large number of connections could be accepted by > the server. I'm still debugging to be sure that no blocking calls happen in > application code. But my question is, what is recommended config for async, > non-blocking servlets? Shall I explicitly enable non-blocking mode? > > I'm using dropwizard 0.9.2 with the following config > > server: > gzip: > bufferSize: 8KiB > minThreads: 32 > applicationConnectors: > - type: http > port: 80 > acceptorThreads: 2 > selectorThreads: 4 > outputBufferSize: 8KiB > > Thanks for your help! > > -- 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.
