При попытке выполнить задачи, которые могут потерпеть неудачу из-за временных или постоянных ограничений на какой-либо ресурс, я склонен использовать стратегию отсрочки. Эта стратегия применялась в таких разных вещах, как очередь сообщений и открытие сокетов.
Общий процесс для такой стратегии следующий.
set maxdelay to 16 # maximum time period between attempts
set maxtries to 10 # maximum attempts
set delay to 0
set tries to 0
while more actions needed:
if delay is not 0:
sleep delay
attempt action
if action failed:
add 1 to tries
if tries is greater than maxtries:
exit with permanent error
if delay is 0:
set delay to 1
else:
double delay
if delay is greater than maxdelay:
set delay to maxdelay
else:
set delay to 0
set tries to 0
Это позволяет процессу работать на полной скорости в подавляющем большинстве случаев, но отключается, когда начинают возникать ошибки, надеясь, что у поставщика ресурсов будет время для восстановления. Постепенное увеличение задержек позволяет восстанавливать более серьезные ограничения ресурсов, и максимальное количество попыток улавливает то, что вы бы назвали постоянными ошибками (или ошибками, восстановление которых занимает слишком много времени).
Я на самом деле предпочитаю этот подход "попробуй и поймай неудачу", чем метод "проверяй, ладно, потом, попробуй", так как последний все еще может часто терпеть неудачу, если что-то меняется между проверкой и попыткой. Это называется метод «лучше искать прощения, чем просить разрешения» , который также довольно хорошо работает с боссами большую часть времени и немного реже жен: -)
Одним из особенно полезных случаев была программа, которая открывала отдельный сеанс TCP для каждой краткосрочной транзакции. На старом оборудовании закрытые сокеты (находящиеся в состоянии TCP WAIT) в конечном итоге исчезли, прежде чем они были необходимы снова.
Но поскольку аппаратное обеспечение стало быстрее, мы обнаружили, что можем открывать сеансы и выполнять работу намного быстрее, а в Windows не хватает дескрипторов TCP (даже при увеличении до максимума).
Вместо того, чтобы перепроектировать протокол связи для поддержки сеансов, эта стратегия была реализована для того, чтобы обеспечить постепенное восстановление дескрипторов событий.
Конечно, это немного сложно, но это было устаревшее программное обеспечение, которое подошло к концу срока службы, где исправления ошибок часто бывают достаточными для того, чтобы они работали, и они не считались достаточно стратегическими, чтобы оправдывать большие затраты на исправление. это правильно.
Обновление: Возможно, существует (более постоянная) проблема с PresentationCore. В этой статье KB говорится, что в WPF есть утечка памяти в .NET 3.5SP1 (из которых ваш драйвер печати может быть клиентом).
Если стратегия возврата не решает вашу проблему (а может, и нет, если это утечка в долгоживущем процессе), вы можете попробовать применить исправление. Я бы повторил проблему на виртуальной машине, а затем исправил бы ее, чтобы протестировать (но я крайне параноик).
Он был найден путем поиска в Google PresentationCore Insufficient memory to continue the execution of the program и проверки первой ссылки здесь . Найдите строку "исправление, относящееся к этой проблеме" на этой странице.