1
У нас есть веб-службы, основанные на aiohttp, которые используют ZMQ для отправки рабочих мест работникам и ждут результата. Мы, конечно, используем ZMQ eventloop, поэтому мы можем подождать Розетки ZMQ. «Иногда» процесс происходит сбой, и мы получаем эту трассировку стеки:ZMQ сбой «случайно» в веб-службе aiohttp
...
await socket.send(z, flags=flags)
File "/usr/local/lib/python3.5/dist-packages/zmq/eventloop/future.py", line 165, in send
kwargs=dict(flags=flags, copy=copy, track=track),
File "/usr/local/lib/python3.5/dist-packages/zmq/eventloop/future.py", line 276, in _add_send_event
timeout_ms = self._shadow_sock.sndtimeo
File "/usr/local/lib/python3.5/dist-packages/zmq/sugar/attrsettr.py", line 45, in _getattr_
return self._get_attr_opt(upper_key, opt)
File "/usr/local/lib/python3.5/dist-packages/zmq/sugar/attrsettr.py", line 49, in _get_attr_opt
return self.get(opt)
File "zmq/backend/cython/socket.pyx", line 449, in zmq.backend.cython.socket.Socket.get (zmq/backend/cython/socket.c:4920)
File "zmq/backend/cython/socket.pyx", line 221, in zmq.backend.cython.socket._getsockopt (zmq/backend/cython/socket.c:2860)
«Иногда» означает, что код работает отлично, если я просто запустить его на моей тестовой машине. Мы столкнулись с проблемой в некоторых редких случаях, когда использовали докерные контейнеры, но никогда не смогли воспроизвести ее надежным способом. Поскольку мы перемещали наши контейнеры в кластер Kubernetes, это происходит гораздо чаще. Кто-нибудь знает, что может быть источником вышеупомянутой трассировки стека?