ThreadPool.QueueUserWorkItem在Web服务的“射后不理”的任务 [英] ThreadPool.QueueUserWorkItem in Web Service for “Fire and Forget” task

查看:509
本文介绍了ThreadPool.QueueUserWorkItem在Web服务的“射后不理”的任务的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是ASP.NET ASMX Web服务/ .NET框架4.0。

This is ASP.NET ASMX Web Service / .NET Framework 4.0.

在Web服务,我想在另一个线程像执行一个方法,射后不理,使Web服务返回的某些值响应立即网站。在另一个线程的方法可能需要10分钟后Web服务立即向网站返回的响应。另外,我不需要这个方法的返回值。

In web service, I want to execute one method on another thread something like "Fire and Forget" so that Web Service returns some value in response immediately to web site. That method on another thread could take 10 minutes after Web Service returns response immediately to Web site. Also, I do not need return value of that method.

我已经使用ThreadPool.QueueUserWorkItem测试这种情况下,似乎线程开始使用线程池仍然会继续执行,即使Web服务返回响应返回给Web站点。我是正确吗?也就是有没有更好的方式来实现这一目标?

I have tested this scenario using ThreadPool.QueueUserWorkItem and it seems that thread started using ThreadPool will still keep executing even after Web Service returns response back to Web site. Am I correct here? Also is there a better way to achieve this?

推荐答案

问题是,每一个现在,然后,ASP.NET将回收应用程序池。因为它不知道你的后台任务,它不会被认为是当应用程序域配置将被中止。

The problem is that every now and then, ASP.NET will recycle the app pool. Because it doesn't know about your background task, it will not be considered and will be aborted when the AppDomain is disposed.

在大多数情况下,工作将完成,但如果您运行足够长的时间,你会遇到这种情况。

Most of the time, the work will complete, but if you run for long enough, you will encounter this scenario.

有两种解决方法:

1)中的正确的方法是编写ASP.NET运行之外的Windows服务。您可以通过WCF发送指令到服务。

1) The "proper" way is to write a Windows Service that runs outside ASP.NET. You can send instructions to the Service over WCF.

2)的快速和肮脏的方法是在它永远不会被用户在你的ASP.NET网站写一个隐藏的Web服务。你的应用程序启动异步请求隐藏的服务,然后返回其自身的结果提供给用户,而无需等待。

2) The "quick and dirty" way is to write a hidden web service in your ASP.NET site that is never called by users. Your app starts an asynchronous request to the hidden service and then returns its own result to the user, without waiting.

ASP.NET不知道请求到隐藏的服务来自于你的应用程序里面 - 它只是把它当作另一个请求。因为ASP.NET知道这一要求,也不会放弃它时,它回收。

ASP.NET does not know that the request to the hidden service came from inside your app - it just treats it as another request. Because ASP.NET knows about this request, it will not abort it when it recycles.

这篇关于ThreadPool.QueueUserWorkItem在Web服务的“射后不理”的任务的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆