我正在开发一个ASP.NET网站，在某些请求上会运行一个非常冗长的缓存过程。 我想知道如果在代码处理它的情况下它仍在运行时达到执行超时会发生什么。
特别是我想知道的事情，如果代码是在try / finally块的尝试将最终仍然运行？
另外，我不确定我是否希望缓存终止，即使它继续进行那么长时间有产生新线程等的方法，我可以绕过这个执行超时？ 我认为立即返回用户说“缓存构建正在发生”而不是让他们超时会更好。 我最近开始玩一些锁定代码，以确保一次只发生一个缓存构建，但我正在考虑扩展它以使其失去同步。
我并没有真正使用过像我这样的线程，所以我不确定它们是如何工作的，特别是在与ASP.NET的交互方面。 例如，如果启动它的父线程终止将对生成的线程产生任何影响？
我知道这里有很多不同的问题，如果这被认为是最好的，我可以将它们分开，但它们似乎都在一起...我会尝试总结这些问题：
如果在try块中由ASP.NET终止线程，则仍会执行finally块 新创建的线程是否会受到与原始线程相同的超时？ 新创建的线程是否会与创建它们的父线程同时死亡？ 在ASP.NET站点上执行长时间运行后台进程的最佳方法是什么呢？对于一些无聊的问题我很抱歉，我从来没有真正玩过线程，他们仍然有点恐吓我（我的大脑说他们很难 ）。 我可以测试很多问题的答案，但我对自己的测试不够自信。 :)
编辑添加：
回应资本G：
我遇到的问题是ASp.NET执行超时当前设置为一小时，这对我认为的某些进程来说并不总是足够长。 我已经把一些东西放进了锁中，以防止不止一个人引发这些长进程，我担心锁可能不会被释放（如果最终阻止并不总是运行，我猜可能会发生）。
您对不在ASP.NET中运行长进程的评论是我考虑将它们移动到其他线程而不是阻塞请求线程的原因，但我不知道这是否仍然算作在您所说的ASP.NET体系结构中运行坏。
代码实际上不是我的，所以我不允许（并且不确定我100％理解它）将其重新编写成服务，尽管这肯定是它最适合居住的地方。
在这种情况下使用BackgroundWorker进程可能需要花费一个小时的时间（对于ASP.NET中长时间运行的进程的注释）。 然后我会请求返回一个“缓存正在构建”页面，直到它完成，然后回到正常服务...这有点噩梦，但它的工作，所以我必须找到一种方法来改善它。 :)
I'm working on a ASP.NET website that on some requests will run a very lengthy caching process. I'm wondering what happens exactly if the execution timeout is reached while it is still running in terms of how the code handles it.
Particularly I am wondering about things like if the code is in the try of a try/finally block will the finally still be run?
Also given I am not sure I want the caching to terminate even if it goes on that long is there a way with spawning new threads, etc. that I can circumvent this execution timeout? I am thinking it would be much nicer to return to the user immediately and say "a cache build is happening" rather than just letting them time out. I have recently started playing with some locking code to make sure only one cache build happens at a time but am thinking about extending this to make it run out of sync.
I've not really played with creating threads and such like myself so am not sure exactly how they work, particularly in terms of interacting with ASP.NET. eg if the parent thread that launched it is terminated will that have any effect on the spawned thread?
I know there is kind of a lot of different questions in here and I can split them if that is deemed best but they all seem to go together... I'll try to summarise the questions though:
Will a finally block still be executed if a thread is terminated by ASP.NET while in the try block Would newly created threads be subject to the same timeouts as the original thread? Would newly created threads die at the same time as the parent thread that created them? And the general one of what is the best way to do long running background processes on an ASP.NET site?Sorry for some noobish questions, I've never really played with threads and they still intimidate me a bit (my brain says they are hard). I could probably test the answer to a lot of tehse questions but I wouldn't be confident enough of my tests. :)
Edit to add:
In response to Capital G:
The problem I have is that the ASp.NET execution timeout is currently set to one hour which is not always long enough for some of these processes I reckon. I've put some stuff in with locks to prevent more than one person setting off these long processes and I was worried the locks might not be released (which if finally blocks aren't always run might happen I guess).
Your comments on not running long processes in ASP.NET is why I was thinking of moving them to other threads rather than blocking the request thread but I don't know if that still counts as running within the ASP.NET architecture that you said was bad.
The code is not actually mine so I'm not allowed (and not sure I 100% understand it enough) to rework it into a service though that is certainly where it would best live.
Would using a BackgroundWorker process for something that could take an hour be feasible in this situation (with respect to comments on long running processes in ASP.NET). I would then make request return a "Cache is building" page until its finished and then go back to serving normally... Its all a bit of a nightmare but its my job so I've got to find a way to improve it. :)
最满意答案
有趣的问题，刚刚测试过，并且不能保证在finally块中执行代码，如果线程被中止，它可以在处理中的任何点停止。 您可以设计一些健全性检查和其他机制来处理特殊的清理例程等，但它也与您的线程处理有很大关系。
不一定，这取决于您实现线程的方式。 如果你自己使用线程，那么你可以很容易地进入父线程被杀死的情况，而它的子线程仍处于处理状态，你通常想要在父线程中做一些清理，结束子线程。 有些对象也可能会为你做很多事情，所以说这种方式很难。 永远不要假设这一点。
不，不一定，至少不要假设这一点，再次与您的设计有关，以及您是在做自己的线程还是使用更高级别的线程对象/模式。 不管怎么说，我绝不会这么想。
我建议不要在ASP.NET体系结构中长时间运行进程，除非它在典型的超时时间内，如果它在10-20秒内没问题，但是如果它是几分钟，不是，原因是ASP.NET中的资源使用情况，而且它非常糟糕。用户。 也就是说你可以执行异步操作，然后将工作交给服务器，然后在处理完成后返回给用户（这对于那些10-20s +进程非常有用），可以给用户一点点动画或其他方式没有让他们的浏览器长时间等待服务器上发生的任何事情发生。
如果它是一个长时间运行的进程，需要超过30-60s +的东西，除非由于进程的性质绝对必须在ASP.NET中完成，我建议将它移动到Windows服务并以某种方式安排它在需要时发生。
注意：线程可能很复杂，并不是很难，因为你必须非常清楚自己在做什么，这需要深入了解线程是什么以及它们是如何工作的，我不是专家，但我m也不是全新的，我会告诉你，在大多数情况下你不需要进入线程领域，即使看起来像你做的那样，但是如果必须的话，我会建议将BackgroundWorker对象视为它们是为了进行批量处理等而简化的（老实说，对于许多需要线程的情况，这通常是一个非常简单的解决方案）。
http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
Interesting question, just tested and no it's not guaranteed to execute the code in the finally block, if a thread is aborted it could stop at any point in the processing. You can design some sanity checking and other mechanisms to handle special cleanup routines and such but it has a lot to do with your thread handling as well.
Not necessarily, it depends on how your implementing your threads. If you are working with threads yourself, then you can easily get into situations where the parent thread is killed while it's child threads are still out there processing, you generally want to do some cleanup in the parent thread that ends the child threads as well. Some objects might do a lot of this for you as well, so it's a tough call to say one way or the other. Never assume this at the very least.
No, not necessarily, don't assume this at least, again has to do with your design and whether your doing threading yourself or using some higher level threading object/pattern. I would never assume this regardless.
I don't recommend long running processes within the ASP.NET architecture, unless its within the typical timeout, if it's 10-20s okay but if it's minutes, no, the reason is resource usage within ASP.NET and it's awfully bad on a user. That being said you could perform asynchronous operations where you hand off the work to the server, then you return back to the user when the processing is finished, (this is great for those 10-20s+ processes), the user can be given a little animation or otherwise not have their browser all stuck for that long waiting for whatever is happening on the server to happen.
If it is a long running process, things that take greater than 30-60s+, unless it absolutely has to be done in ASP.NET due to the nature of the process, I suggest moving it to a windows service and schedule it in some way to occur when required.
Note: Threading CAN be complicated, it's not that it's hard so much as that you have to be very aware of what your doing, which requires a firm understanding of what threads are and how they work, I'm no expert, but I'm also not completely new and I'll tell you that in most situations you don't need to get into the realm of threading, even when it seems like you do, if you must however, I would suggest looking into the BackgroundWorker object as they are simplified for the purposes of doing batched processing etc. (honestly for many situations that DO need threads, this is usually a very simple solution).
http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
更多推荐
发布评论