Re: [jetty-users] Requests not being rejected even with QueuedTheadPool

[Michael Ryan <mryan@xxxxxxxxxxxx>]

Thanks. This seems to be working as I'd like it.

Some tips for other people who use this:
- The parameters are named "waitMs" and "suspendMs", not "waitMS" and "suspendMS".
- The default timeout in AsyncContinuation (which effectively is the default suspendMs) is 30000ms. You'll probably want to set suspendMs to something lower than this. I just used 1ms, so that the request quickly returns a 503.
- At least in Jetty 8, the request log will show a 200 response code for these rejected requests, and this will be logged at the time at which the request is suspended, rather than at the time at which the request is rejected/completed. The actual rejection response code (503) is not logged.
- maxRequests should be lower than ThreadPool's maxThreads, otherwise it's the ThreadPool size that will be the bottleneck (in which case you'll get the unbounded queue behavior I described previously).

-Michael

-----Original Message-----
From: jetty-users-bounces@xxxxxxxxxxx [mailto:jetty-users-bounces@xxxxxxxxxxx] On Behalf Of Jesse McConnell
Sent: Friday, January 31, 2014 9:31 AM
To: JETTY user mailing list
Subject: Re: [jetty-users] Requests not being rejected even with QueuedTheadPool limit

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
jesse.mcconnell@xxxxxxxxx


On Thu, Jan 30, 2014 at 5:38 PM, Michael Ryan <mryan@xxxxxxxxxxxx> 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(SelectChannelEndPo
> int.java:225):Dispatched
> Failed!” and
> “DBUG:oejut.QueuedThreadPool:oejut.QueuedThreadPool#dispatch(QueuedThr
> eadPool.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
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users