Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-users] Requests not being rejected even with QueuedTheadPool limit

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


Back to the top