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

1

Я использую библиотеку потока данных TPL для реализации потребительского сценария производителя. Обработка включает в себя конвейер задач. Библиотека потока данных точно подходит для моего использования.

Но я хочу знать, как эффективно реализовать этот прецедент [подробнее см.].

Я хочу использовать поток данных TPL в настройке типа сервера.

По типу типа сервера я подразумеваю, что процесс создания потока данных происходит непрерывно [асинхронно] навсегда. Задача потребления также выполняется навсегда и потребляет все данные, производимые производителем [асинхронно]. Таким образом, мои блоки работают вечно

Как я могу правильно моделировать этот сценарий? Более того, как я могу справиться с обработкой исключений, поскольку я не могу Wait() [Без вызова Wait() я не смог бы поймать исключения, которые были сброшены на поврежденный блок, насколько я понимаю).

  • 0
    Рассмотрите Реактивные Расширения (Rx) вместо этого. Поведение потока данных TPL заключается в том, что после сбоя в сети блоков он остается неисправным.
Теги:
exception-handling
task-parallel-library
tpl-dataflow

1 ответ

0
Лучший ответ

Исключения

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

var block = new TransfromBlock<string, int>(number =>
{
    try
    {
        return int.Parse(number);
    }
    catch (Exception e)
    {
        Trace.WriteLine(e);
    }
});

Вместимость

Еще одна важная проблема - укупорка. Если какая-то часть вашего рабочего процесса не может справиться с нагрузкой, очередь ввода просто будет расти бесконечно. Это может привести к утечке памяти или OutOfMemoryException. Поэтому важно следить за тем, чтобы ограничить все блоки с помощью соответствующего BoundedCapacity и решить, что делать, когда достигнут этот предел ("бросить" предметы, сохранить на хранение и т.д.).

параллелизм

Хотя значение по умолчанию для BoundedCapacity - -1 (неограниченное), значение по умолчанию для MaxDegreeOfPrallelism равно 1 (без параллелизма). Большинство приложений могут легко извлечь выгоду из параллелизма, поэтому обязательно установите соответствующее значение MaxDegreeOfPrallelism. Когда делегат блока имеет чисто ЦП, MaxDegreeOfPrallelism не должен быть намного выше доступных ядер. Так как у него меньше процессорных и более интенсивных элементов ввода/вывода, MaxDegreeOfPrallelism можно увеличить.

Вывод

Использование потока данных TPL в течение всего жизненного цикла приложения очень просто. Просто убедитесь, что вы можете настроить конфигурацию через app.config и настроить в соответствии с фактическими результатами "в поле".

Ещё вопросы

Сообщество Overcoder
Наверх
Меню