При попытке выполнить задачи, которые могут потерпеть неудачу из-за временных или постоянных ограничений на некоторый ресурс, я склонен использовать стратегию отступления. Эта стратегия соблюдается в таких разнообразных вещах, как очередь сообщений и сокет.
Общий процесс для такой стратегии заключается в следующем.
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
Это позволяет процессу работать на полной скорости в подавляющем большинстве случаев, но отступит, когда ошибки запуска происходит, мы надеемся, давая время поставщика ресурсов для восстановления. Постепенное увеличение задержек позволяет восстановить более серьезные ограничения ресурсов, и максимальные попытки поймают то, что вы назвали бы перманентными ошибками (или ошибками, которые слишком долго восстанавливаются).
Я на самом деле предпочитаю этот метод try-it-and-catch-failure для проверки, если все в порядке, а затем попробуйте один, поскольку последний может все еще часто терпеть неудачу, если что-то меняется между проверкой и попыткой. Это называется «лучше просить прощения, чем спрашивать разрешения» метод, который также хорошо работает с боссами большую часть времени, и жен немного реже :-)
Один особенно полезный случай был программа, открыла отдельную TCP-сессию для каждой короткоживущей транзакции. На более старых аппаратных средствах закрытые сокеты (те, в состоянии TCP WAIT) в конечном итоге исчезли, прежде чем они были необходимы снова.
Но, по мере того, как аппаратное обеспечение ускорялось, мы обнаружили, что мы можем открывать сеансы и работать намного быстрее, а Windows заканчивается из ручек TCP (даже при увеличении до max).
Вместо того, чтобы перестроить протокол связи для ведения сеансов, эта стратегия была реализована, чтобы обеспечить изящное восстановление в ручках событий.
Предоставлено, что это немного клочья, но это устаревшее программное обеспечение приближается к концу жизни, где исправления ошибок часто достаточно, чтобы заставить его работать, и он не считался стратегическим, чтобы гарантировать тратить много денег в исправляя его должным образом.
Update: Может быть, что есть (более постоянны) проблема с PresentationCore. В этом KB article указано, что в WPF в .NET 3.5SP1 есть утечка памяти (из которой ваш драйвер печати может быть клиентом).
Если стратегия отсрочки не устраняет вашу проблему (может быть, это не так, как утечка в долговечном процессе), вы можете попробовать применить исправление. Я, я бы реплицировал проблему на виртуальной машине, а затем исправил ее, чтобы проверить ее (но я крайний параноик).
Было найдено по ошибке в поисковых системах PresentationCore Insufficient memory to continue the execution of the program и проверке первой ссылки here. Найдите строку "исправление, относящееся к этой проблеме" на этой странице.