asp.net问题中的线程 - 线程停止 [英] Threading in asp.net issue - Thread stops

问题描述

我有一个带有一个按钮的简单asp.net页面。

在OnClick事件中，我想创建一个执行a的线程

long runninf任务。

以下是OnClick中的示例代码




Thread t = new Thread（new ThreadStart（this.Import））;

t.Priority = ThreadPriority.Lowest;

t.Start（）;


导入功能


public void导入（）

{

for（int i = 0; i< 100; i ++）

{

Response.Write（i.ToString（）+"< br>"）;

Thread.Sleep（100）;

}

}


问题是我的线程很快停止工作。在这个

的例子中，线程只显示从0到9的数字......而不是

100 ...

有什么特别之处吗？我现在应该在

asp.net中运行线程？

请建议。

祝你好运

Philippe GRACA

解决方案

问题是ASP.NET线程继续并将响应返回给客户端，无论您的线程是否正在运行。


你正在做的是一个非常糟糕的想法（tm），因为你得到了大量的请求，你将用无上限的线程杀死你的服务器（我见过类似的设置）在咨询工具上的服务器上转储6000个线程我做了一段时间后回来了。


你想通过使用backgourd线程来实现什么？ ASP.NET已经是高度多线程的，因此很少需要异步运行一些请求。


问候


Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk




我有一个带有一个按钮的简单asp.net页面。

在OnClick事件中，我想创建一个将执行

long runninf任务的线程。

Thx Richards

我几乎可以肯定这是一个坏主意;）

我想做的是通过网络界面向我们的用户提出

加载5或6真正巨大的能力在/或
的App数据库中进行XML文件（> 100 Mb）（进行XSL转换，然后批量插入到sql

服务器）。这应该几乎立即按需完成，因为他们确实不想等待任何类型的批次或其他什么。一旦加载了这些文件

，他们就可以执行比较和许多其他的b $ b任务。

我们最后，导入的工作需要大约13分钟完成，但在用户方面，他们遇到了TCP问题（连接是
丢失，但工作确实仍在运行!!）。我虽然关于这个

线程方法基本上考虑将一个正在运行的线程

与ASP.NET分开，这样用户就不会失去HTTP

连接。我同意这是解决问题的不好方法，也许

异步Web服务可以解决问题。您如何看待

？任何想法，评论，代码分享？

问候和好我们:)

Philippe GRACA


" Richard Blewett [ DevelopMentor的] QUOT; < RI ****** @ NOSPAMdevelop.com>在消息新闻中写道：< OC ************** @ TK2MSFTNGP12.phx.gbl> ...

问题是ASP.NET线程继续并将响应返回给客户端，无论您的线程是否正在运行。

您正在做的是一个非常糟糕的想法（tm），因为您收到大量请求将要杀死您的服务器有一个无上限的线程（我已经在咨询工具的服务器上看到类似的设置转储6000个线程我做了一段时间）。

你想通过使用backgourd实现什么？线。 ASP.NET已经是高度多线程的，所以很少需要异步运行一些请求。

理查德·布莱维特 - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

在OnClick事件中，我想创建一个执行
long runninf任务的线程。

Phil< ph ************ @ hotmail.com>写道：

我几乎肯定这是一个坏主意;）
我想做的是通过网络界面向我们的用户提出
能力在App数据库中加载5或6个非常庞大的XML文件（每个> 100 Mb）（执行XSL转换，然后批量插入到sql
服务器）。这应该几乎立即按需完成，因为他们不想等待任何类型的批次或其他什么。一旦这些文件被加载，他们就可以执行比较和许多其他任务。
最后，导入工作需要大约13分钟才能完成，但是
用户方面，他们遇到TCP问题（连接丢失但工作确实仍在运行!!）。我虽然关于这种线程方法本质上是考虑将一个正在运行的线程与ASP.NET分开，这样用户就不会失去HTTP
连接。我同意这是解决问题的坏方法，也许是异步Web服务可以解决问题。你怎么看待那个？任何想法，评论，代码分享？

有一个长期运行的线程做这项工作是合理的，但不要

有一个长期运行的请求。有一个简短的请求，有效地发送一个

响应另一个20秒后再次检查。 （使用

HTTP META-REFRESH或其他）并继续这样做，直到
运行作业完成，此时它会显示结果。如果它b / b
每次刷新时都能显示出有意义的进度估计值，那就更好了。


-

Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet

如果回复群组，请不要给我发邮件

Hi,
I''ve a simple asp.net page with one button.
In the OnClick event, I want to create a thread that will perform a
long runninf task.
Here is a sample code

in the OnClick

Thread t = new Thread(new ThreadStart(this.Import));
t.Priority = ThreadPriority.Lowest;
t.Start();

Import Function

public void Import()
{
for (int i=0;i<100;i++)
{
Response.Write(i.ToString() + "<br>");
Thread.Sleep(100);
}
}

The issue is that my thread stop working really quickly. In this
example, the thread only display figures from 0 to 9... instead of
100...
Is there something special I should now about running threads in
asp.net?
Please advice.
Best regards
Philippe GRACA

解决方案

Well the problem is that the ASP.NET thread continues and returns the response to the client, irrespective of your thread running.

What you are doing is A Really Bad Idea (tm) as you get a large number of requests you are going to kill your server with an uncapped number of threads (I''ve seen a similar setup dump 6000 threads on a server on a consulting gig I did a while back).

What are you trying to achieve by using a backgourd thread. ASP.NET is highly multithreaded already so it is rarely necessary to run bits of requests asynchronously.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,
I''ve a simple asp.net page with one button.
In the OnClick event, I want to create a thread that will perform a
long runninf task.

Thx Richards
I was almost sure this was a bad idea ;)
What I''m trying to do is to propose to our users via a web interface
the capability to load 5 or 6 really huge XML files( > 100 Mb each) in
the App database (doing XSL tranform and then bulk inserts to sql
server). This should be done on demand almost immediatly since they do
not want to wait for any kind of batch or whatever. Once those files
are loaded, they can then perform comparisons and a lot of other
tasks.
On our end, the import job take around 13 minutes to complete but on
the user side, they are experiencing TCP problems (the connection is
lost but the job is indeed still running!!) . I though about this
threading approach essentially thinking of having a running thread
separate from the ASP.NET one so that users won''t loose the HTTP
connection. I agree this is the bad way to solve the problem and maybe
an aynchronous Web service will do the trick. What do you think of
that? Any ideas, comment, code to share?
Regards and nice we :)
Philippe GRACA

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in message news:<OC**************@TK2MSFTNGP12.phx.gbl>...

Well the problem is that the ASP.NET thread continues and returns the response to the client, irrespective of your thread running.

What you are doing is A Really Bad Idea (tm) as you get a large number of requests you are going to kill your server with an uncapped number of threads (I''ve seen a similar setup dump 6000 threads on a server on a consulting gig I did a while back).

What are you trying to achieve by using a backgourd thread. ASP.NET is highly multithreaded already so it is rarely necessary to run bits of requests asynchronously.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,
I''ve a simple asp.net page with one button.
In the OnClick event, I want to create a thread that will perform a
long runninf task.

Phil <ph************@hotmail.com> wrote:

I was almost sure this was a bad idea ;)
What I''m trying to do is to propose to our users via a web interface
the capability to load 5 or 6 really huge XML files( > 100 Mb each) in
the App database (doing XSL tranform and then bulk inserts to sql
server). This should be done on demand almost immediatly since they do
not want to wait for any kind of batch or whatever. Once those files
are loaded, they can then perform comparisons and a lot of other
tasks.
On our end, the import job take around 13 minutes to complete but on
the user side, they are experiencing TCP problems (the connection is
lost but the job is indeed still running!!) . I though about this
threading approach essentially thinking of having a running thread
separate from the ASP.NET one so that users won''t loose the HTTP
connection. I agree this is the bad way to solve the problem and maybe
an aynchronous Web service will do the trick. What do you think of
that? Any ideas, comment, code to share?

It''s reasonable to have a long-running thread doing the job, but don''t
have a long-running request. Have a short request which sends a
response effectively saying "Check again in another 20 seconds" (using
an HTTP META-REFRESH or whatever) and keeps doing so until the long-
running job has finished, at which point it displays the results. If it
can display a meaningful estimate of the progress each time it
refreshes, that''s even better.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

这篇关于asp.net问题中的线程 - 线程停止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！