Dropwizard / Jetty REST在中等负载下调用返回http状态202

Question

我遇到了一个基于dropwizard 0.7.1.3构建的休息服务的问题，我认为它嵌入了Jetty 0.9.7.1.v20131107。

该服务具有各种REST端点设置，其中一些用于提交后台任务，一些用于检查所述作业的状态，最后，一些用于在完成时检索作业的结果。要清楚......这些端点都没有明确返回202。

我正在对应用程序进行一些负载测试，它模拟多个用户同时点击服务，以便提交作业，检查其状态并检索结果。对于大约30个用户的模拟超过30秒，在几分钟的过程中有大约3500个请求提交给服务。平均速度约为16 /秒。在此期间，我看到偶尔从某些端点返回202 http状态代码。如果我增加用户数量，202s的频率也会增加。

在负载测试期间对应用程序进行概要分析时，可用的CPU和堆空间似乎都保持在合理的范围内。垃圾收集也是如此。此外，使用的线程数远低于服务的最大设置数，大约为1024 ...我看到可能分配了175个。

我现在处于一个我无法弄清楚导致这些202的原因的地方。我已尝试在drop wizard config中增加acceptor线程，选择器线程等设置，但它们无助于缓解此问题。

我已经尝试使用Google搜索有关导致Jetty返回202的情况的信息，但我也找不到任何有用的信息。

之前有没有人遇到过这样的问题？谁能告诉我Jetty在什么情况下会决定返回202而不是实际处理请求？为了缓解这个问题，我可能会改变什么？

对我来说，平均16个请求/秒足以保证返回202是没有意义的。如果有任何其他信息可能有助于诊断这一点，请告诉我。

Answer 1

注意：这个问题太不明确了，我会举报。但我的评论并不符合规模要求。

如果您 absolutely sure 指责Jetty，您可以检查一些奇怪的Jetty QoS或DoS过滤器配置。它们的默认返回码是HTTP 503 Service unavailable，但返回码是可配置的。

IMO返回HTTP 202状态代码似乎是应用程序的预期行为。 IANA状态的HTTP状态代码的官方注册表：

  

202 Accepted RFC7231, Section 6.3.3

     

202回复是故意不置可否的。其目的是为了   允许服务器接受某个其他进程的请求（也许是   没有的批处理过程，每天只运行一次   要求用户代理与服务器的连接一直持续到   这个过程完成了。与此响应一起发送的表示   应该描述请求的当前状态并指向（或嵌入）   状态监视器，可以为用户提供何时的估计   请求将被履行。

作为面向批处理的过程，您可以想象例如将几GB文件导出到某个Web服务器或类似S3的对象存储。服务器接受了请求，成功指示了该过程中涉及的其他系统，并告诉您该任务已启动。它不能立即提供结果。您可以在何时何地找到结果取决于应用程序，并且必须使用它来检查文档。

Answer 2

最后，我们发现内部公司库中确实有一些代码在非常具体的情况下返回202。