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

Question

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

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

_sock.timeout -1, _sock.gettimeout не None

Там я ничего особенного не делаю в основном потоке (просто получая вызовы 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 дней, пытаясь выяснить истинную причину.

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