It would be more correct to use something like the QoS filter we provide: http://www.eclipse.org/jetty/documentation/current/qos-filter.html
This way you can choose the number of requests you want (20 in your case) and limit accordingly with the other requests getting a SERVICE_UNAVAILABLE response. The threadpool is used for all of the async io processing so it is not a 1 to 1 correlation to a servlet request (unless using servlet 2.5 and sort of async servlet support). cheers, jesse -- jesse mcconnell [email protected] On Thu, Jan 30, 2014 at 5:38 PM, Michael Ryan <[email protected]> wrote: > I’m trying to configure jetty (v 8.1.9) to reject requests if there are > already XXX requests being processed. Basically I just want it to tell me > that it is full, rather than eating forever and blowing up J. As I’ve > learned, the default behavior is to accept an unlimited number of > connections. > > > > I’ve followed the instructions at > http://wiki.eclipse.org/Jetty/Howto/High_Load#Thread_Pool to specify a limit > on the size of the queue used by QueuedTheadPool. Here’s an example of > something I’ve tried: > > <Set name="ThreadPool"> > > <New class="org.eclipse.jetty.util.thread.QueuedThreadPool"> > > <Arg> > > <New class="java.util.concurrent.ArrayBlockingQueue"> > > <Arg type="int">25</Arg> > > </New> > > </Arg> > > <Set name="minThreads">10</Set> > > <Set name="maxThreads">20</Set> > > <Set name="detailedDump">false</Set> > > </New> > > </Set> > > > > This is not limiting the number of connections. I’ve got a servlet that > takes about 10s to process a request, and I’m sending 1000 requests at it. > With the configuration above, I’d expect that ~20 requests would hit the > servlet immediately, 25 would sit in the queue, and ~955 would be rejected. > No requests are being rejected. After the first 20 finish, another 20 go, > then another 20, until all 1000 finish. > > > > While they are processing, I get hundreds of thousands of > “WARN:oeji.nio:oejin.SelectChannelEndPoint#dispatch(SelectChannelEndPoint.java:225):Dispatched > Failed!” and > “DBUG:oejut.QueuedThreadPool:oejut.QueuedThreadPool#dispatch(QueuedThreadPool.java:371):Dispatched > org.eclipse.jetty.io.nio.SelectChannelEndPoint[…] to stopped qtp[…]” > messages in the log. > > > > I’ve confirmed with jmap that the queue indeed is being bounded to 25. > Tracing through jetty’s code, it seems that QueuedThreadPool offers the job > to its queue, the queue rejects it, and dispatch() returns false to the > caller. But somewhere up the chain (maybe in SelectorManager?), it just > keeps calling dispatch() in a tight loop, rather than taking the false > return value to mean “please stop, I can’t eat anymore”. > > > > So, what am I doing wrong? Is configuring the thread pool not the way to do > this? > > > > -Michael > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
