Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Dropwizard/Jetty REST calls returning http status 202 under moderate-to-light load

Thanx for confirming the issue is not with Jetty Joakim. I will keep digging into this... as you said it must be an issue in one of the third party or internal libraries we are using. 


On Tue, Nov 15, 2016 at 4:01 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
Jetty 0.9.7.1.v20131107 is not a valid version of Jetty.

The "202 Accepted" response is not a status code produced by any component in Jetty.

The 202 you are getting is from some component outside of Jetty, likely one of your libraries.

Joakim Erdfelt / joakim@xxxxxxxxxxx

On Tue, Nov 15, 2016 at 12:00 PM, David White <davidjosephwhite78@xxxxxxxxx> wrote:

Hi folks,

I'm running into an issue with a rest service built on dropwizard 0.7.1.3, which i believe is has Jetty 0.9.7.1.v20131107 embedded. 

The service has various REST endpoints setup, where some are used to submit a background task, some are used for checking status of said job, and lastly, some are used to retrieve the results of the job when it is completed. To be clear... none of these endpoints are explicitly returning 202.

I'm currently doing some load testing of the application where it is simulating multiple users hitting the service simultaneously in order to submit jobs, check their status and retrieve results. For a simulation of about 30 users ramped up over 30 seconds, there are about 3500 request submitted to the service over the course of a couple minutes. The average rate is about 16/second. During this time, i see the occasional return of 202 http status code from some of the endpoints. If i increase the number of users, the frequency of 202s increases as well. 

During profiling of the application while load testing, the CPU and heap space available both seem to stay within reasonable bounds. The same goes for garbage collection. Also, the number of threads in use is much lower than the maximum set for the service which is about 1024... i see maybe 175 allocated.

I'm at a point now where I can't seem to figure out what is causing these 202s. I've tried increasing acceptor threads, selector threads, etc settings in drop wizard config but they don't help to alleviate the problem.

I've tried googling for information on what circumstances cause Jetty to return a 202 but i can't find any useful information on this either. 

Has anyone experienced an issue such as this before ? Can anyone tell me under what circumstances Jetty will decide to return a 202 versus actually process the request ? and what i might be able to change in order to alleviate the problem ?

It just doesn't make sense to me that an average rate of 16 requests/second would be enough to warrant returning 202. If there is any additional information that might help to diagnose this, please let me know. Thanx very much.

-DaViS


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top