Jetty using fixed-length queues, resulting in inability to service __jetty performance optimizations

later, look at the jetty source code for the following reasons:

question:

1. Web application-dependent Third-party services are temporarily suspended (using httpclient calls), resulting in a surge in demand (client retry mechanism), jetty stop service. (Front machine nginx-> different servers (Nginx and jetty))

Phenomenon:

1. Jetty output A large number of request allocation failure log is as follows:

2016 18:59:25.828 WARN nio[243]-dispatched failed! Scep@34b2eaa5{l (/127.0.0.1:29829) <->r (/127.0.0.1:8080), S=-1,open=true,ishut=false,oshut=false,rb=false, Wb=false,w=true,i=0}-{asynchttpconnection@4e4b11aa,g=httpgenerator{s=0,h=-1,b=-1,c=-1},p=httpparser{s=-14,l=0, C=0},r=0} to org.eclipse.jetty.server.nio.selectchannelconnector$connectorselectormanager@7839e749

2.linux server close_wait increased dramatically:

3. Service quickly unavailable, temporary solution to nginx cut flow, restart Jetty,jetty use httpclient call request recovery.

Solve:

1. Jetty configuration file, use default queue (at that time fixed length queue, is to prevent Jetty Gluttonous, lead to jetty collapse problem, currently in nginx current limit solution)

Problem:

1. Why use fixed-length queues, there will be dispatched Failed?

1 The use of fixed-length queues, when the httpclient request for a third service, the Third-party service problems, thread pool threads are blocked in the request for Third-party services, 2 external requests continue to come up, the queue is full, the request to continue to come over, will use the Discard task strategy, It will output dispatched Failed
2. Why does the server appear a large number of close_wait?
1) through Ss-ant | awk ' {++s[$1]} end {for (k. s) print K,s[k]} ' command looks at each state, finds Close_wait majority, and is the same server nginx traffic to this server jetty
2) View Nginx log: 2015/11/24 16:38:56 [ERROR] 25941#0: *15256 upstream timed out (110:connection timed out) while reading Respo NSE header from upstream, client:
3 through the log and close_wait screenshots, mainly jetty send a lot of segment, each time timeout, resulting in nginx closed socket, resulting in close_wait status.

3. Why use the default unbounded queues, the system is no problem.

1 The use of unbounded queues, all requests can be dispatch to the thread processing, when the use of Httpcliet to invoke a Third-party service problems, because HttpClient has timed out, Web applications automatically turn off httpclient (so jetty is invoked as a client HttpClient service does not appear close_wait)

2 at this time, relative to Nginx, jetty did not appear dispatched failed error, but wait to get httpclient link timeout, automatically close the link. Instead of the Nginx end, the close_wait state is not present.

Note:

1. Attached jetty use filter current limiting scheme: http://www.eclipse.org/jetty/documentation/current/qos-filter.html#qos-understanding