Главная » Дизайн дома » Разумное использование объекта Session. Смотреть что такое "аккомпанировать" в других словарях

Разумное использование объекта Session. Смотреть что такое "аккомпанировать" в других словарях

This tutorial attempts to shed some light on the subject of Threading using ASP.NET. Threading is a technique used to give the user the impression that multiple tasks are executing at the same time. The .NET Framework provides us with many types that allow us to easily and quickly add multi-threading to our .NET Web application. I’ll assume that you have some familiarity with ASP.NET and at least some experience with writing code in Visual Basic.

Through the tutorial we’ll build a pretty simple Web application that should be a good example of some basic threading concepts. Basically we’ll have 2 textboxes in which to enter a phrase, and to enter a time period in which you want the phrase to be rebuilt. Our Web threading application consists of 2 pages, one of which is the page that will start the thread, while the other is a results page that shows us the progress of our thread. The code provided should be very portable and allow you to implement your own threading application very quickly.

Before we get started…

Before we dive into the Web application, let me first give you a quick look at some of the code that you’ll be seeing.

First, we need to import the System.Threading Namespace so we can access the Thread class provided in the .NET Framework. Add this line to the top of your .aspx/.ascx file:

<%@ Import NameSpace="System.Threading" %>

Imports System.Threading

Now for demonstration purposes, here is a sample long running method. In a real life situation this method would most likely perform a task like processing a Web form, or completing a time-consuming database query.

Public Sub SomeLongMethod()

"your code that takes a while to execute

Now to execute this method and not leave our Web form hanging, we’ll start a new thread and let SomeLongMethod execute on this new thread. To do this, we have a few options. The technique I’ll use is to set up a new method that will start our new thread running. Here’s a sample thread starter function:

Public Sub SomeLongMethod_Thread()

"first, declare a new Thread, passing the constructor the address
"of SomeLongMethod. NOTE: SomeLongMethod can be replaced with your
"own method

Dim NewThread As Thread = New _
Thread(AddressOf SomeLongMethod)

"next we set the priority of our thread to lowest, setting
"the priority to a higher level can cause unexpected results.
NewThread.Priority = ThreadPriority.Lowest

"finally we start the thread executing
NewThread.Start()

And that’s it! All we have to do now is replace our call to SomeLongMethod with a call to SomeLongMethod_Thread , and the long method will execute on its own thread. Normally, we would redirect the user to the results page at the end of the SomeLongMethod_Thread method. However in this example I left that out to prevent confusion — I’ll demonstrate it in the following example, which illustrates the use of Threading in an ASP.NET Web application.

Using Threading to Rebuild a String

The first file we’ll look at is default.aspx. This will be the page where we’ll get 2 values from the user, and start a new thread. The second file we’ll look at is the results page, where we’ll poll the Session variables created in the thread, and display current thread stats to our user. I’ll go through default.aspx method-by-method, and then do the same for the results.aspx page. The source code for this file is available at the end of this tutorial.

NOTE: I’ve assumed that your Web server has Session variables enabled. If you have Session variables Disabled, or you have cookies disabled on your browser, the results of the following example will not display correctly.

A Simple Example (default.aspx)

Let’s begin by looking at the Page_Load function for default.aspx

Sub Page_Load(ByVal sender As System.Object, ByVal e
As System.EventArgs)

SyncLock Session.SyncRoot
"here, we initialize 3 session variables to hold our results
Session("Complete") = False
Session("Status") = ""
Session("Phrase") = ""
End SyncLock
d Sub

In this method we simply initialize 3 session variables that we’ll use in our next few methods. Session("Complete") will be the sentinel for our results page. When the thread is complete we will set Session("Complete") to True . The Session("Phrase") variable will be what we use to hold our partial phrase as we slowly build it. Session("Status") is just a variable to hold the start time and the end time. Now let’s look at our phrase re-building method:

Sub PhraseBuilder()

Dim str As String = ""
Dim i As Integer = 0

Dim startTimeTicks As Long = 0
Dim strStartTime As String = ""

Dim totalSleepTime As Double = 0.0

"log our start time, in ticks, and in Long Date format
startTimeTicks = DateTime.Now.Ticks
strStartTime = "Thread Started: " & DateTime.Now

" get phrase
str = txtPhrase.Text

"convert users time from seconds to milliseconds
totalSleepTime = 1000.0
totalSleepTime = totalSleepTime * CInt(txtTotalThreadLife.Text)
totalSleepTime = (totalSleepTime / str.Length)

For i = 0 To str.Length - 1

"this method will put our thread to sleep for the specified
"number of milliseconds. without the sleep, this method would
"execute too fast to see the thread working.
Thread.Sleep(totalSleepTime)

"we use synclock to block any other thread from accessing
"session variables while we are changing their values.
SyncLock Session.SyncRoot

Session("Status") = "Thread is " & _
Format((i / (str.Length - 1)) * 100, "#0.00") & _
"% complete." & " - Time Elapsed: " & _
Format((DateTime.Now.Ticks - startTimeTicks) / 10000000 _
, "#0.00") & " sec. Target: " & txtTotalThreadLife.Text & _
".00 sec."

SyncLock Session.SyncRoot
"rebuild phrase 1 letter at a time
Session("Phrase") &= str.Chars(i).ToString
End SyncLock

"our method is complete, so set the Session variables
"accordingly
SyncLock Session.SyncRoot
Session("Status") = strStartTime & _
"
Thread Complete. End Time: " & DateTime.Now & "
"

Session("Complete") = True
End SyncLock

Ok, now let’s dissect this method a little. Basically what we’re doing here is forcing a method that would otherwise run quickly to run on a schedule based on user input. This is done using the Thread.Sleep(ByVal millisecond as Integer) method. This method allows us to put the thread to sleep for the specified number of milliseconds. This Sleep method can be used in any method, not just one that’s executing on a new thread.

The other interesting technique we utilize is the use of the Synclock method. Synclock is used to block other threads from trying to obtain the same Synclock . To protect the variables from simultaneous access, we need to obtain the same Synclock before we access the variables everywhere else in the code. This is a necessity in a multi-threaded Web application to ensure that two methods aren’t reading/writing to the same variable at the same time. The Synclock method is identical to using the Monitor.Enter(Me) method that’s also provided in the System.Threading Namespace .

There are only two methods left to go! The next method we’ll look at is the PhraseBuilder_Thread function. This function is almost identical to the example at the beginning of the article:

Sub PhraseBuilder_Thread()

"method to start our phrase builder method executing
"on a new thread.

Dim myThread As Thread = New Thread(AddressOf PhraseBuilder)

MyThread.Priority = ThreadPriority.Lowest

"//start the new thread
myThread.Start()

"now redirect to the results page
Response.Redirect("results.aspx")

Now all that’s left is to call our PhraseBuilder_Thread method when the user clicks the submit button. Here’s the short code:

Sub btnSubmit_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs)

"start PhraseBuilder thread...
PhraseBuilder_Thread()
End Sub

A Simple Example(results.aspx)

Now we’ll take a look at the results page. Basically our results page will check the status of the Session("completed") variable on the Page_Load , and react accordingly. Here’s the Page_load function for results.aspx:

Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
"Put user code to initialize the page here
"check the value of Session("Completed"), if it is True, stop writing

If Session("Complete") <> True Then

"make sure session variables are enabled, if not warn user

If Session("Complete") <> False Then
"error with session variable, Session("Complete") is not
"True or False
lblComplete.Text = "Error with Session("Complete")"

"set page to auto refresh page every 2 seconds, until thread is done

Response.Write("")

SyncLock Session.SyncRoot
lblStatus.Text = Session("Status") & "
Processing. . ."

End SyncLock

Else
"thread is complete, stop writing refresh tag, and display
"results
SyncLock Session.SyncRoot
lblStatus.Text = Session("Status")
lblPhrase.Text = Session("Phrase")
lblComplete.Text = Session("Complete")
End SyncLock

This Page_Load function checks the status of the Session("Complete") variable and reacts accordingly. Feel free to customize you results page to suit you needs, but I recommend checking for the case when the Session("Completed") variable is not set to True, or False. This usually happens when Session variables are disabled, or you have cookies disabled. Also, you can remove the Response.Write statement if you don’t want the page to automatically refresh.

In Conclusion

Well that’s all there is to it! Hopefully you have just written your first ASP.NET application using threading.

WebBackgrounder

As it says "WebBackgrounder is a proof-of-concept of a web-farm friendly background task manager meant to just work with a vanilla ASP.NET web application." Its code hasn"t been touched in years, BUT the WebBackgrounder NuGet package has been downloaded almost a half-million times.

The goal of this project is to handle one task only, manage a recurring task on an interval in the background for a web app.

If your ASP.NET application just needs one background task to runs an a basic scheduled interval, than perhaps you just need the basics of WebBackgrounder.

Using System;
using System.Threading;
using System.Threading.Tasks;

namespace WebBackgrounder.DemoWeb
{
public class SampleJob: Job
{
public SampleJob(TimeSpan interval, TimeSpan timeout)
: base("Sample Job", interval, timeout)
{
}

Public override Task Execute()
{
return new Task(() => Thread.Sleep(3000));
}
}
}

Built in: QueueBackgroundWorkItem - Added in .NET 4.5.2

Somewhat in response to the need for WebBackgrounder, .NET 4.5.2 added QueueBackgroundWorkItem as a new API . It"s not just a "Task.Run," it tries to be more:

QBWI schedules a task which can run in the background, independent of any request. This differs from a normal ThreadPool work item in that ASP.NET automatically keeps track of how many work items registered through this API are currently running, and the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing.

It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can"t finish in 90 seconds, then you"ll need a different (and more robust, meaning, out of process) technique.

The API is pretty straightforward, taking Func. Here"s an example that kicks of a background work item from an MVC action:

Public ActionResult SendEmail( User user)
{
if (ModelState.IsValid)
{
HostingEnvironment.QueueBackgroundWorkItem(ct => SendMailAsync(user.Email));
return RedirectToAction("Index", "Home");
}

Return View(user);
}

FluentScheduler

FluentScheduler is a more sophisticated and complex scheduler that features a (you guessed it) fluent interface. You have really explicit control over when your tasks run.

Using FluentScheduler;

public class MyRegistry: Registry
{
public MyRegistry()
{
// Schedule an ITask to run at an interval
Schedule().ToRunNow().AndEvery(2).Seconds();

// Schedule a simple task to run at a specific time
Schedule(() => Console.WriteLine("Timed Task - Will run every day at 9:15pm: " + DateTime.Now)).ToRunEvery(1).Days().At(21, 15);

// Schedule a more complex action to run immediately and on an monthly interval
Schedule(() =>
{
Console.WriteLine("Complex Action Task Starts: " + DateTime.Now);
Thread.Sleep(1000);
Console.WriteLine("Complex Action Task Ends: " + DateTime.Now);
}).ToRunNow().AndEvery(1).Months().OnTheFirst(DayOfWeek.Monday).At(3, 0);
}
}

FluentScheduler also embraces IoC and can easily plug into your favorite Dependency Injection tool of choice by just implementing their ITaskFactory interface.

Quartz.NET

Quartz.NET is a .NET port of the popular Java job scheduling framework of the (almost) same name. It"s very actively developed. Quartz has an IJob interface with just one method, Execute, to implement.

Using Quartz;
using Quartz.Impl;
using System;

namespace ScheduledTaskExample.ScheduledTasks
{
public class JobScheduler
{
public static void Start()
{
IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
scheduler.Start();

IJobDetail job = JobBuilder.Create().Build();

ITrigger trigger = TriggerBuilder.Create()
.WithDailyTimeIntervalSchedule
(s =>
s.WithIntervalInHours(24)
.OnEveryDay()
.StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
.Build();

Scheduler.ScheduleJob(job, trigger);
}
}
}

Then, inside your Application_Start, you call JobScheduler.Start(). There"s a great getting started article on Quartz at Mikesdotnetting you should check out.

Hangfire

And last but definitely not least, the most polished (IMHO) of the group,

Последнее обновление: 10.03.2016

Одним из ключевых нововведений последних версий фреймворка.NET стала асинхронность. Хотя фреймворк и раньше позволял использовать асинхронные методы, но с появлением библиотеки Task Parallel Library работа с асинхронным кодом была предельно упрощена, а сам формат работы изменился. Были добавлены новые возможности по созданию асинхронных методов с использованием новых ключевых слов, таких как async и await.

При создании нового контроллера мы в настройках уже можем указать, как нам нужен контроллер - синхронный или асинхронный. По умолчанию Visual Studio добавляет в проект стандартные контроллеры, методы которых, как правило, возвращают объект ActionResult. Но если мы при добавлении контроллера в папку Controllers выберем тип MVC 5 Controller with views, using Entity Framework , то в окне настройки нового контроллера специальное поле позволит нам указать, что новый контроллер будет содержать асинхронные методы:

Для чего нужны вообще асинхронные методы в контроллерах? Асинхронные методы позволяют оптимизировать производительность приложения и предназначены прежде всего для обработки таких запросов, которые занимают или могут занять довольно продолжительное время, например, обращение к базе данных или обращение к внешнему сетевому ресурсу для получения большой порции данных. Применение асинхронных методов позволяет приложению параллельно с выполнением асинхронного кода выполнять также другие запросы.

Чтобы понять различие между синхронными и асинхронными методами, рассмотрим, как IIS обрабатывает входящие запросы. Веб-сервер поддерживает пул потоков, которые обслуживают запросы. При обращении пользователя к веб-ресурсу IIS выделяет поток из пула для обслуживания данного запроса. И пока данный поток не обработает предназначенный для него запрос, другие запросы он обрабатывать не может.

Однако предположим, что метод контроллера в процессе обработки запроса должен выполнить запрос к другому ресурсу или к базе данных. Запрос к сетевому ресурсу или БД сам по себе может занять некоторое время. При синхронной обработке поток, обрабатывающий запрос, временно блокируется, пока сетевой ресурс или БД не возвратят нужные нам данные.

И если обработка запроса блокируется очень долго, то IIS начинает задействовать для обслуживания других входящих запросов новые потоки. Однако есть ограничения на общее количество потоков. Когда количество потоков достигает предела, то вновь входящие запросы помещаются в очередь ожидания. Однако и тут есть ограничение на количество запросов в очереди. И когда это количество превышает предел, то IIS просто отклоняет все остальные запросы с помощью статусного кода 503 (Service Unavailable).

При асинхронной обработке поток не ждет, пока БД вернет ему данные, а начинает обрабатывать запрос от другого пользователя. Но когда, наконец, с сетевого ресурса или БД придут нужные данные, поток возвращается к обработке ранее обрабатываемого запроса в обычном режиме.

Перейдем непосредственно к коду. Для создания асинхронных методов используются модификаторы async и await , которые позволяют выполнять продолжительные операции без блокирования основного потока.

Сравним на примере вызов синхронного и асинхронного метода:

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; using AsyncContollers.Models; using System.Threading.Tasks; using System.Data.Entity; namespace AsyncContollers.Controllers { public class HomeController: Controller { BookContext db = new BookContext(); public ActionResult Index() { IEnumerable books = db.Books; ViewBag.Books = books; return View(); } // асинхронный метод public async Task BookList() { IEnumerable books = await db.Books.ToListAsync(); ViewBag.Books = books; return View("Index"); } } }

Оба метода выполняют одну и ту же операцию - извлечение данных из БД и получают идентичные результаты. Но если первый синхронный метод Index представляет привычную для нас запись, то асинхронный метод BookList уже выглядит необычно.

Этот метод возвращает не объект ActionResult, а объект Task . Task представляет асинхронную операцию, выполняющуюся продолжительное время.

Кроме того, чтобы обозначить метод как асинхронный, перед возвращаемым типом ставится ключевое слово async .

Третьим ключевым моментом является использование ключевого слова await . Оно применяется в асинхронных методах, чтобы приостановить выполнение этого метода до тех пор, пока ожидаемая задача не завершится. В нашем случае такой задачей является получение данных из БД.

Но также следует учитывать, что await используется с методами, возвращающими объект Task . Поэтому для получения данных из БД используется метод await db.Books.ToListAsync() , который также извлекает данные из БД, но уже в асинхронном режиме.

Когда следует использовать асинхронные методы? В первую очередь их предпочтительно использовать при запросах к БД, к внешнем сетевым ресурсам, однако в конечном счете, что лучше синхронность или асинхронность решает уже сам разработчик исходя из конкретной задачи.

Об опасностях выполнения фоновых задач в ASP.NET. Он выделил три основных риска, связанных с запуском фонового процесса:

Необработанное исключение в потоке, несвязанном с запросом, может снять процесс.
Если запустить сайт в веб-ферме, то есть вероятность случайно завершить несколько экземпляров приложения, которое могло запустить несколько экземпляров одной и той же задачи одновременно.
Домен приложения, в котором запущен сайт, по разным причинам может выгрузиться и снять фоновую задачу, запущенную в нем.

Конечно, можно написать собственный менеджер для управления фоновыми задачами. Но, вероятнее всего, Вы сделаете это неправильно. Никто не собирается оспаривать Ваши навыки разработчика. Просто создание подобного менеджера - это достаточно тонкая вещь. Да и зачем Вам это надо?

Есть множество отличных вариантов запуска задач в фоновом режиме. И не просто абстрактных методик, а готовых библиотек.

Какие-то ASP.NET приложения могут работать на Ваших собственных серверах под IIS, какие-то размещаться в Azure.

Для запуска фоновых задач можно выделить несколько вариантов:

HANGFIRE

И последний в обзоре, но, безусловно, непоследний по функциональности, наиболее продвинутый из всех Hangfire. Это действительно очень продвинутый фреймворк для фоновых задач в ASP.NET. Опционально он может использовать Redis, SQL Server, SQL Azure, MSMQ или RabbitMQ для повышения надежности выполнения задач.

Документация Hangfire действительно превосходна. Хотелось бы, чтобы каждый проект с открытым исходным кодом имел такую документацию.

Одной из самых эффектных функций Hangfire является встроенная аналитическая панель, которая позволяет просматривать расписания, выполняющиеся задания, успешные и неуспешно завершенные задания.

Hangfire позволяет легко определить задачи типа «запустить и забыть», информация о которых будет храниться в базе данных:

BackgroundJob.Enqueue(() => Console.WriteLine("Fire-and-forget"));
Можно отсрочить выполнение задачи:

BackgroundJob.Schedule(() => Console.WriteLine("Delayed"), TimeSpan.FromDays(1));
Или запустить задачу в CRON стиле

RecurringJob.AddOrUpdate(() => Console.Write("Recurring"), Cron.Daily);
Работать с Hangfire очень удобно. Hangfire имеет хорошую документацию и обучающие руководства , основанные на реальных примерах.

Hangfire - это целая экосистема для работы с фоновыми задачами в ASP.NET приложениях.

Библиотеки доступны в виде открытых исходных кодов или Nuget пакетов.

Итоги (лично от себя)

Выбирая библиотеку для себя, я, с одной стороны, хочу иметь приличную функциональность, а с другой, пока не хочу использовать, например, базу данных для хранения информации о запущенных задачах. Поэтому простые решения типа WebBackgrounder или QueueBackgroundWorkItem я даже не стал рассматривать.

Я уже знаю, что мне нужно запускать больше одного процесса, и работать процессы могут долго (ограничение в 90 секунд на завершение в QueueBackgroundWorkItem). FluentScheduler выглядит неплохо, но хотелось большего. Hangfire – отличное решение, но, вроде, сразу требует использования базы данных для хранения очереди задач. Да и не совсем там все бесплатно – есть и платная версия.

В итоге я пока выбрал Quartz.NET: вполне приличная документация, достаточное количество примеров, чтобы быстро начать использовать, а также расширяемый функционал, который можно добавлять по мере возрастания потребностей.

Если вы знаете другие библиотеки для запуска фоновых задач или имеете опыт решения подобных задач – делитесь в комментариях.

Для ресайзинга картинок вы можете использовать готовое решение – imageresizing.net. Оно выполнено в виде HTTP Module для ASP.NET и производит ресайзинг картинок "на лету". То есть во время загрузки картинки производится только ее загрузка, без трансформаций. Ресайзинг же производится тогда, когда запрашивается специфичный размер самой картинки и выполняется асинхронно, поскольку страница уже отображается у пользователя. Также используется кэш, чтобы избежать постоянной регенерации картинок.

Но так как вопрос был про "многопоточность asp.net", то поделюсь соображениями еще и по этой теме. Сразу скажу, что есть готовое решение – HangFire , но также интересны и причины его появления.

В ASP.NET каждый запрос выполняется внутри отдельного потока. Так как создание потока является достаточно "дорогой" операцией, то для каждого запроса отдается "в аренду" готовый поток из пула потоков.

В интернете ходит множество слухов, что долгоиграющие запросы ASP.NET могут "забить" все потоки из пула, и новые запросы будут нещадно попадать в request queue и ожидать своей очереди на исполнение. Такая ситуация называется Thread pool starvation (или thread pool contention) и приводит к снижению пропускной способности сервера при увеличении количества запросов.

Однако начиная с IIS 7 количество доступных потоков в ASP.NET приложении достаточно большое . Но так как ресайзинг картинки является cpu intensive задачей, то снижение пропускной способности все-таки может произойти из-за нехватки ресурсов процессора, которая усугубляется дорогими и постоянными переключениями между потоками.

В ASP.NET в общем и в ASP.NET MVC в частности есть понятие асинхронной обработки запросов. В MVC 3 был AsyncController, начиная с MVC 4 и C# 5.0 была введена поддержка async-методов . Однако в этой программной модели запрос должен ждать завершения всех асинхронных операций, и в вашем случае получится, что вы отдаете ресайз картинки на выполнение в другом потоке, и ожидаете его завершение в потоке, который исполняет запрос. В этом случае вы ничего не выигрываете, и даже проигрываете, потому что вместо одного потока на обработку запроса начинает выделяться два потока.

В ASP.NET приложении вы также можете либо создать поток самостоятельно (что плохо, потому что это дорогая операция), либо использовать некоторый пул предварительно инициированных потоков самостоятельно, либо использовать тот же самый Thread Pool (посредством Task-based API либо ThreadPool.QueueUserWorkItem) и не ожидать его завершения, при этом ресайз картинки будет происходить вне пределов контекста обработки запроса. В этом случае пользователю не нужно будет ожидать завершения долгой операции, но здесь может возникнуть следующая проблема.

Если в качестве веб-сервера выступает IIS (что скорее всего так, пока Owin не пошел в массы), то ваше приложение хостится в одном или нескольких рабочих процессах IIS, которые работают под управлением пула приложения. А пул приложения имеет множество всевозможных настроек, которые могут привести к recycling"у приложения . Это хороший процесс, который экономит ресурсы сервера, особенно на shared хостингах. Вот только у него есть таймаут на его завершение, который по-умолчанию равен 90 секундам.

Когда application pool начинает процесс ресайклинга, он отсылает ASP.NET приложению команду на остановку (shutdown). При этом само ASP.NET приложение перестает принимать новые запросы, и ждет завершения текущих с собственным дефолтным таймаутом (ShutdownTimeout в конфиге application pool) в 30 секунд. Если текущие запросы успевают выполниться за отведенное время, то сразу после этого происходит выгрузка домена приложения.

Вот тут и кроется первая проблема – ASP.NET по-умолчанию просто не обращает внимания на все ваши фоновые потоки, как созданные собственноручно, так и потоки из Thread Pool. И если после завершения обработки текущих запросов ваша фоновая задача не была завершена – это ваши проблемы, она будет просто прервана исключением ThreadAbortException. И если не были предприняты конкретные шаги по ее перезапуску, то сами потом будете объяснять пользователям, почему иногда картинки или отчеты до них так и не доходят. Конечно же, вероятность вроде бы небольшая, но запросов много, причин у recycling"а много, да и время жизни проекта тоже большое. А бороться с последствиями довольно неприятно.

Еще в ASP.NET есть интерфейс IRegisteredObject и методы HostEnvironment.RegisterObject и HosterEnvironment.UnregisterObject (а вот и ), которые уведомляют ASP.NET о том, что есть операция, завершения которой нужно ожидать при получения события об остановке приложения. Правда вот ShutdownTimeout при этом никуда не девается, а гарантировать, что все фоновые задачи будут завершены за 30 секунд очень сложно.

Так что основная проблема – это вероятность прерывания потока, выполняющего задачу из-за таймаутов. Я лично ловил несколько раз такие исключения, и разрешение последствий иногда было довольно неприятной штукой. Увеличивать же таймауты не совсем разумно, поскольку именно они помогают приложению сохранять хоть какую-то стабильность, когда возникают гораздо большие проблемы по совершенно другим причинам.

В этой ситуации 100% работающее решение – написать собственное приложение, которое будет "крутиться" постоянно и оформить его в виде службы Windows. Она будет перезапускаться гораздо реже, и таймауты можно настроить так, как душе угодно. Однако в добавок нужно еще организовать протокол общения (тут можно взять, конечно WCF), и разработать грамотную модель обработки задач. Но и первоначальная разработка, и последующее тестирование несколько сложно. А оправдать такое монстроидальное решение тем, что "нам нужна гарантия при ресайзе картинок" бывает тоже довольно трудно.

Самым обидным для меня было то, что для Ruby on Rails было полно всяких решения, которые решали подобную проблему с long-running процессами на стороне веб-сервера на общий манер: Resque , Sidekiq , delayed_job и иже с ними. Для платформы.NET есть несколько разработок на NuGet, но они пока еще слишком слабые, и иногда не дают гарантий того, что задача будет выполнена всегда после ее создания.

Подождав год-другой, я решил все-таки сделать подобный общий инструмент для.NET – HangFire . На данный момент у него версия 0.7, что означает его неполную готовность для массового использования, однако он гораздо стабильнее и функциональнее, чем большинство собственных разработок. Плюс, он сейчас находится в активной разработке. Схема и публичное API довольно стабильно, и оно уже используется в нашей системе, которая находится в продакшене. Так что можете попробовать, а если возникнут вопросы – то смело создавайте тикет на гитхабе.

Напечатать