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 <[email protected]> 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 / [email protected] > > On Tue, Nov 15, 2016 at 12:00 PM, David White < > [email protected]> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
