在处理单向WCF操作时，是否可以保证IIS何时可以回收？ 背景

这个问题分为两部分

我在IIS 6中托管了一个单向WCF操作。以下是我对其工作原理的理解：

_一,。IIS收到一个请求

_二,。IIS发送HTTP 202响应（谢谢，我稍后会处理）

_三,。IIS调用我的单向WCF操作

现在，控制传递到我的WCF操作，该操作执行以下操作：

_四,。将请求信息持久化到事务性持久存储区

_五,。开始在OLTP数据库中处理请求

_六,。如果出现错误，请从步骤5重复，或采取一些补救措施，然后清除步骤4中保留的数据

问题1 我对IIS何时发送HTTP 202响应的理解是否正确

问题2 如果IIS在第2步和第4步之间循环使用，我可能会在进行保留请求信息的更改之前，但在客户端认为我已接受消息之后，丢失请求信息。IIS是否提供了任何关于当有未决请求时它将或不将回收的保证

---

---

PS：请原谅这些不可靠的格式。由于某种原因，markdown完全搞乱了我的编号列表项。

在我看来，我有几点建议：

据我所知，在IIS中管理进程回收的唯一方法是查看您的网站正在使用的应用程序池。如果打开IIS管理器->应用程序池->选择您的池，然后右键单击“属性”，在“回收”选项卡上，有一些选项可能会对您有所帮助。我想这并不能保证你不会在循环中丢失请求，但是设置更长的时间可以降低发生这种情况的概率

---

然而，听起来您想要构建的系统似乎是MSMQ的理想候选系统，它可以提供异步服务请求，这些请求以很少的开销或手动管道正确排队。这将允许您完全避免整个流程的回收问题。我不确定这是否是您的方案的一个选项，但这可能是需要研究的问题。

我不确定您的假设是否正确

即使是单向交互，在返回202之前，WCF也可能会被卷入其中；例如，如果使用身份验证，则必须在调用该方法和返回202之前进行验证，以便在出现任何问题时可以报告这些问题

例如，如果使用wsHttpBinding，开箱即用，您将看到2-3次消息交换，结果在实际方法调用之前发生200次。这是为了交换安全信息和建立安全上下文

诚然，如果您将服务配置为没有安全性，则不会发生这种情况，它将立即返回202，但这表明它必须知道是否可以从WCF堆栈中执行此操作

撇开这些不谈——我不确定你想要实现什么——你指的是哪种IIS回收？我不是IIS方面的专家，但我怀疑它会在某些东西正在积极执行时回收主机；如果您指的是任何手动限制应用程序池（或IIS，或机器）的人，我怀疑您能做多少

---

如果您必须确保消息不会丢失，那么我所知道的保证消息丢失的唯一方法就是以某种方式使用可靠的消息传递，这种方式只会确认持久存储中保存的请求

我想他提到的回收是IIS中基于threashold的回收特性（时间、请求、内存等）。对于所有这些阈值，当存在正在进行的事务或请求时，IIS不会回收工作进程（w3wp.exe）。IIS将停止向具有挂起回收的w3wp.exe发送新请求。有一个进程运行状况ping，IIS将通过该ping检测w3wp.exe是否仍处于活动状态并正常运行，并且当请求处于活动状态且进程运行状况良好时，不会发生回收。有一个超时。查看IIS进程模型参考页以了解确切的值。这真的回答了问题吗？我显然认为它回答了：-），您认为哪一位没有回答？谢谢您的回答，Steve。不幸的是，它没有完全涵盖我要找的。在这种情况下，MSMQ是不可能的，因为它是一个从前端web服务器（MSMQ不可用）进行处理的系统，这给我们带来了同样的问题。也就是说，在发送202响应之前，我们必须确保能够通过IIS从客户机获取消息并将其放入队列。