gpt4 book ai didi

c# - 如何防止 Azure Web 角色中重复的 HTTP 请求

转载 作者:太空宇宙 更新时间:2023-11-03 10:35:05 26 4
gpt4 key购买 nike

我们间歇性地看到重复的 HTTP 请求到达我们的 Azure 云服务应用程序。我们的应用程序使用 Azure 流量管理器在两个区域之间分配流量(用于灾难恢复目的)。我们每个区域有 3 个大型 Web 角色实例。

有人在 Azure 中遇到过(最好是解决了)类似的问题吗?

更多细节如下:

<强>1。跟踪记录:

跟踪日志记录是在 MVC Controller 操作中实现的,该操作似乎是重复的:

    [HttpPost]
public JsonResult JsonPost(FormCollection formData)
{
Logger.Info(LogFormatter.FormatMessage(ToString(), "JsonPost", UserHelper.CustomerSession.CustomerId, "Begin JSON post."));
var result = new DefaultJsonResult();
try
{
#region Build and validate foo model
var fooModel = BuildFooModel(formData);
.
.
.
}
catch (Exception ex)
{
Logger.Error(LogFormatter.FormatException(ex, ToString(), "JsonPost",
UserHelper.CustomerSession.CustomerId, "Error while proccessing Foo."));
result.Success = false;
result.Action = new JsonResultAction(JsonResultActionType.Display);
result.Error = new JsonResultError();
result.Error.Details.Add(new JsonResultErrorDetail
{
Type = "FooProcessing",
Message = "Error while proccessing Foo."
});
}
Logger.Info(LogFormatter.FormatMessage(ToString(), "JsonPost", UserHelper.CustomerSession.CustomerId, "End JSON post."));

return Json(result);
}

在跟踪日志中,我们看到以下多个实例:

Message: Calculating bar.
Timestamp: 01/22/2015 03:42:28
Controller Name: Com.Web.Controllers.FooController
Action Name: bar
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=15;

Message: Begin JSON post.
Timestamp: 01/22/2015 03:43:22
Controller Name: Com.Web.Controllers.FooController
Action Name: JsonPost
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=28;

Message: Sending Foo Notification
Timestamp: 01/22/2015 03:43:28
Controller Name: Com.Web.Business.Modules.Foo.FooModule
Action Name: ProcessFoo
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_0; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=28;

Message: Begin JSON post.
Timestamp: 01/22/2015 03:43:30
Controller Name: Com.Web.Controllers.FooController
Action Name: JsonPost
User Id: 85c5d33f-05b3-40d5-9e73-1219ca490e7e
RoleInstance=StoreWebApp_IN_2; WindowsIdentity.Name=NT AUTHORITY\NETWORK SERVICE; ManagedThreadId=13;

一些值得注意的事情:

  1. 第二个“Begin JSON post”发生在第一个请求记录其“End JSON post”(顺便说一句,从未记录)之前

  2. 第二个“开始 JSON 帖子”发生在另一个 Web 角色实例上

<强>2。 IIS 日志:

对应的IIS日志如下:

2015-01-22 03:42:29 W3SVC1273337584 RD00155DE0F696 127.0.0.13 POST /foo/bar
- 443 [email protected] 128.0.0.28 HTTP/1.1 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_8_2)+AppleWebKit/536.26.17+(KHTML,+like+Gecko)+Version/6.0.2+Safari/536.26.17

2015-01-22 03:43:30 W3SVC1273337584 RD00155DE0CAC8 127.0.0.54 POST /foo/jsonpost
- 443 [email protected] 128.0.0.28 HTTP/1.1 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_8_2)+AppleWebKit/536.26.17+(KHTML,+like+Gecko)+Version/6.0.2+Safari/536.26.17

此时您可能会问自己第一个 /foo/jsonpost 请求的 IIS 日志条目在哪里?对于重复请求的每个实例,此行为都是一致的,但原因仍然是个谜。

感谢您的阅读。任何关于如何进一步排除故障的见解甚至建议将不胜感激。

<小时/>

谷歌搜索“azure重复请求”产生以下结果:

2015 年 1 月 26 日更新
启用失败请求跟踪,希望捕获幻像(第一个 /foo/jsonpost)请求并隔离它的来源。不幸的是,仍然没有运气,Failed Request Tracing 与 IIS 日志一致。

最佳答案

结案:

由于第三方 API 通信逻辑存在缺陷,导致堆栈溢出,导致日志条目丢失。当 IIS 重新启动时,它会恢复/恢复导致堆栈溢出的请求。因为connection was kept alive throughout the recycle客户端只能看到第二次执行的响应。第二次尝试没有发生堆栈溢出的原因是执行采用了与第一次执行不同的代码路径。

我们如何知道存在堆栈溢出(除了 TODO 注释“防止堆栈溢出”):

  • 在系统事件日志中:“为应用程序池“ASP.NET v4.0”提供服务的进程与 Windows 进程激活服务发生致命通信错误。进程 ID 为“5328”。数据字段包含错误号。"
  • 在 HTTPERR (IIS) 日志中,出现“Connection_Abandoned_By_ReqQueue”错误,这意味着应用程序池中的工作进程意外退出或通过关闭其句柄孤立待处理的请求
  • 崩溃日志显示 0x800703e9 - “递归太深;堆栈溢出。

希望这些发现对其他试图解开 IIS 日志丢失之谜的迷失者有所帮助...

关于c# - 如何防止 Azure Web 角色中重复的 HTTP 请求,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28101075/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com