使用Post方法

Question

我有一个奇怪的问题。让我一步一步详细解释：

1. 我是供应商开发的REST WS（使用WCF制作），用于与MS CRM同步数据。

2. 我开发了一个Windows服务，它从数据库中获取要同步的批量数据，然后使用Post方法将其作为JSON对象传递给此Web服务。 Windows服务部署在其中一个节点上。

3. 我面临的问题从未在Dev，QA，UAT或暂存环境中发生过。它仅适用于生产环境。

4. 在生产中，应用程序有效，然后开始抛出400 Bad request错误。然后，直到我们重新启动站点或重置应用程序池标识，IIS不断抛出400个错误的请求错误。当我们重新启动站点或应用程序池时，那些失败的相同请求开始获得成功的响应。它可以像这样工作一段时间，然后再开始400次。

5. 托管Web服务的环境是Win Server 2012,2节点负载平衡环境。 WS部署在boht节点上的端口8080上，并配置为在.Net 4.0下运行。

6. 我的Windows服务日志中收到以下错误，这是这些WS的客户端。

  

System.Net.WebException：远程服务器返回错误：（400）   错误的请求。          在SspToCrmSynchronizationService.Helpers.CrmWrapperWsHelper.CallService（String   data，String url，String方法，String userName，String password，   CrmWrapperWsHelper.cs中的字符串contentType）：第79行          在SspToCrmSynchronizationService.Helpers.CrmWrapperWsHelper.CallDocumentCreateService（String   数据）在CrmWrapperWsHelper.cs中：第20行          在SspToCrmSynchronizationService.Process.CommonOperations.GenerateJsonAndInvokeDocCreateWS（Int64）   CommonReperations.cs中的appRefNo，Application app）：第52行          在SspToCrmSynchronizationService.Process.SequentialProcess.Process（List`1   appList，DatabaseHelper dbHelperForChildTask，CancellationToken ct）in   SequentialProcess.cs：第88行

1. 首先，我们检查了IIS日志，发现IIS只在少数100 MS中返回400错误。我们怀疑它没有到达WS应用程序，因为应用程序根本没有记录任何东西，尽管Logging the request是供应商在WS代码中做的第一件事。

2. 其次，我们使用Fiddler捕获请求和响应，并获得以下内容：

   HTTP/1.1 400 Bad Request
   Cache-Control: private
   Content-Length: 1647
   Content-Type: text/html
   Server: Microsoft-IIS/8.5
   X-ASpNet-Version: 4.0.30319
   X-Powered-By: ASP.Net
   Date: Tue, 17 Oct 2017 07:14:26 GMT
   



1. 我们检查了IIS Httperr.log。在日志中，我们发现了以下某些请求，而不是每个失败的请求。似乎什么都没有。

  

2017-07-07 03:32:45 10.102.2.52 63726 10.102.2.52 8080 - - - - - Timer_ConnectionIdle -
  2017-07-08 22:46:55 10.102.2.52 50916 10.102.2.52 8080 - - - - - Timer_ConnectionIdle -   2017-07-08 22:55:09 10.102.2.52 51004 10.102.2.52 8080 - - - - - Timer_ConnectionIdle -

1. 我们在IIS中为400配置了失败的跟踪日志，并在抛出此400错误时在跟踪日志中收到一条警告。由于NDA和安全原因，我已从图像中删除了部分数据。



基本上警告的详细信息如下：

124. MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName="ManagedPipelineHandler", 
Notification="EXECUTE_REQUEST_HANDLER", 
HttpStatus="400", 
HttpReason="Bad Request", 
HttpSubStatus="0", 
ErrorCode="The operation completed successfully. (0x0)",
ConfigExceptionInfo=""

1. 之后，我比较了一个错误案例和一个成功案例。下面是图像。我注意到的是，如果失败，General_Read_Entity_Start和General_Read_Entity_End根本没有发生。



我能理解的最大值是，IIS无法以某种方式将JSON字符串解析为某个实体，并且AppPool会崩溃然后开始抛出400个错误，直到AppPool或IIS重置未完成为止。我不知道造成这种情况的原因（根本原因）以及如何解决这个问题，以及为什么它最初工作并且在一段时间后不工作。任何帮助都将受到高度赞赏。

[编辑]

1. 服务器上的资源消耗不到10％。
2. 对于成功案例，WS的平均响应时间为5秒，而对于Error情况，它的返回时间为100毫秒。
3. 我们在测试服务中对大约100多个请求进行了压力测试，一切顺利。

Answer 1

＆＃34;停止工作的时间＆＃34;重启后一样吗？它是否与服务所经历的假定流量呈线性变化？你有压力/尖峰测试服务吗？您是否监控了托管服务器的资源？

如果它似乎只发生在Prod上，它与测试服务器没有什么不同，那么期望Prod被未知数量的来源使用。 首先，我要确保资源与此无关。 （有点疯狂：如果没有违反用户权限，则会将对prod的请求镜像到具有类似功能的测试服务器之一，看看会发生什么）

Answer 2

我们需要了解它是如何工作的，有很多条件：

1. 我们在JSON中传递了一个日期时间值。在WS端，当我们的情况下的WS容器（IIS和WCF）试图将DateTime字段传递给应用程序时，DateTime值抛出了一些解析错误。我相信这可能是由于语言环境。我们通过在WS接受的JSON中将datetime更改为字符串来修复它。

2. 第二个问题是我们的供应商使用WCF作为创建RestAPI的技术。 WCF的一个行为是，如果来自客户端的请求导致致命异常在WS容器中出现，IIS将在阻止列表中注册此客户端，并且不会将请求从同一客户端转发到应用程序，直到IIS重新启动为止完成。 IIS将继续向我们返回Bad Request状态消息。