SimpleXmlRpcServer _sock.rcv зависает после тысяч запросов

Question

Я обслуживаю запросы от нескольких клиентов XMLRPC через WAN. Это прекрасно работает, скажем, один день (иногда два), а затем останавливается в socket.py:

data = self._sock.recv(self._rbufsize)

_sock.timeout равно -1, _sock.gettimeout равно N *

Ничего особенного я не делаю в основном потоке (просто получаю вызовы XMLRPC), есть еще два потока, взаимодействующих с БД. Оба эти потока работают нормально и переживают этот блок (проверил с WinPdb). Клиенты отправляют запросы размером не более 1 КБ, и специального контента нет: просто красивые и чистые строки в словаре. Между двумя блокировками я обслуживаю десятки тысяч запросов без проблем. Брандмауэр выключен, на той же машине нет странного программного обеспечения и т.д ...

Я использую Windows XP и Python 2.6.4. Я проверил различия между 2.6.4. и 2.6.5, и не нашел ничего важного (или я ошибаюсь?). 2.7 версия не вариант, так как я бы пропустил двоичные файлы для MySqlDB.

Единственное, что время от времени происходит из-за клиентов с плохим интернет-соединением, - это разрывы сокетов. Это происходит каждые 5-10 минут (каждые 2 секунды к серверу обращаются только пять клиентов).

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

Answer 1

Что именно происходит в стеке TCP / IP вашей ОС (возможно, в верхних слоях python, но это менее вероятно), потому что это загадка.В качестве практического обходного пути я бы установил тайм-аут, превышающий задержки, которые вы ожидаете между запросами (10 секунд должно быть достаточно, если вы ожидаете запрос каждые 2 секунды), а если он возникает, закройте и снова откройте.(Откалибруйте задержку, необходимую для обхода зависаний, не прерывая нормальный трафик методом проб и ошибок).Я знаю, неприятно взламывать исправления без понимания проблемы, но прагматичный подход к таким вещам является необходимой чертой выживания в мире написания, развертывания и эксплуатации реальных серверных систем.Обязательно прокомментируйте обходной путь для будущих сопровождающих!

Answer 2

большое спасибо за быстрый ответ.Сразу после получения я увеличил время ожидания до 10 секунд.Теперь все работает без проблем, но, конечно, мне нужно подождать еще день или два, чтобы получить какое-то подтверждение, но только через 5 дней я буду уверен и вернусь с результатами.Теперь я вижу, что запрос 140K прошел хорошо, имея такой тяжелый опыт, что я бы подождал еще как минимум 200K.

То, что вы предлагали об автоматической адаптации тайм-аутов (без остановки системы), звучит также разумно,Правильный ли путь - создать небольшой класс (например, AutoTimeoutCalibrator) и встроить его непосредственно в serial.py?

Да - прагматичность - единственный способ без потери еще 10 дней, пытаясь выяснить реальныйпричина позади.

Еще раз спасибо, я вернусь с результатами.(извините, но по какой-то причине я не смог опубликовать это как ответ на ваше сообщение)