【发布时间】:2013-01-25 17:16:54
【问题描述】:
为了帮助提高客户端的性能,我将请求的处理转移到任务上。这样做是因为处理通常需要一些时间,而且我不希望客户端等待一段时间才能获得 200 响应。将工作卸载到任务上的 Web 服务始终在处理帖子。
public void ProcessRequest(HttpContext context)
{
// check for bad requests -- return 400
// get copy of the context input stream
Task.Factory.StartNew(() =>
{
ProcessRequest(contextInputStreamCopy);
});
}
private void ProcessRequest(Stream inputStream)
{
try
{
// process input stream
}
catch(Exception ex)
{
// any server error that would normally result in 500 response are not
// exposed to the clients, the clients are to see 200 when the server
// encounters an error
}
}
所以我的问题是当 IIS 回收或网站停止时这些任务会发生什么。
【问题讨论】:
-
虽然这是一个很好的一般性问题,但请考虑一下它是否真的适用于您的情况。既然您似乎并不关心任务的结果或任务中的任何错误,为什么还要关心它在回收/崩溃时会发生什么?
-
@AlexeiLevenkov 他可能关心已经发生的副作用。如果它正在执行诸如将批量数据插入数据库之类的操作,您不希望它消失或更糟,请保持一半完成。该任务可能会执行 UI 中未显示的错误处理。
-
@AlexeiLevenkov 我确实关心处理的结果,它的客户不应该关心任何错误。我的理解是,任务主体中的一般 try/catch 应该可以防止任务在大多数情况下遇到异常,因此任务会被触发并忘记,它会在完成时完成。
-
@millimoose 你说得对,任务的中止导致我的数据处于错误状态。
-
我明白了。请注意,您感兴趣的问题实际上是“如果我在崩溃/杀死我的 AppDomain 中运行我的代码的进程,如何为我的数据实现事务支持”......我建议接受解释 IIS 行为的答案回收并提出单独的问题,说明您可以在支持事务的情况下进行数据库的原因。
标签: c# asp.net c#-4.0 iis iis-7.5