PARTH P
 · Algo Trader

Exception in thread: BrokenPipeError: [Errno 32] Broken pipe

Hi Fyers Team,

I'm facing an issue while moving my project to Azure app service. Currently my app works flawlessly locally on my win11 machine but when I move to Azure's app service, I receive socket errors.

My Azure deployment is simple app service running on Linux with Python 3.9.

The socket code to get tick data works for some time and fails throwing error below. It seems from my collected logs that it momentarily connects to socket and breaks.

2024-10-01T07:25:38.786523116Z Exception in thread Thread-14:
2024-10-01T07:25:38.793085914Z Traceback (most recent call last):
2024-10-01T07:25:38.793108514Z   File "/opt/python/3.9.19/lib/python3.9/threading.py", line 980, in bootstrapinner
2024-10-01T07:25:38.793114814Z     self.run()
2024-10-01T07:25:38.793118314Z   File "/opt/python/3.9.19/lib/python3.9/threading.py", line 917, in run
2024-10-01T07:25:38.793122014Z     self._target(*self._args, **self._kwargs)
2024-10-01T07:25:38.793125714Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/fyers_apiv3/FyersWebsocket/data_ws.py", line 1646, in __ping
2024-10-01T07:25:38.793129215Z     self.__ws_object.send(bytes([0, 1, 11]), opcode=websocket.ABNF.OPCODE_BINARY)
2024-10-01T07:25:38.793132615Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_app.py", line 249, in send
2024-10-01T07:25:38.793136015Z     if not self.sock or self.sock.send(data, opcode) == 0:
2024-10-01T07:25:38.793139415Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_core.py", line 283, in send
2024-10-01T07:25:38.793142915Z     return self.send_frame(frame)
2024-10-01T07:25:38.793146115Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_core.py", line 311, in send_frame
2024-10-01T07:25:38.793149615Z     l = self._send(data)
2024-10-01T07:25:38.793152915Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_core.py", line 525, in _send
2024-10-01T07:25:38.793156415Z     return send(self.sock, data)
2024-10-01T07:25:38.793159615Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_socket.py", line 170, in send
2024-10-01T07:25:38.793163115Z     return _send()
2024-10-01T07:25:38.793166215Z   File "/tmp/8dce1088ad2f6fc/antenv/lib/python3.9/site-packages/websocket/_socket.py", line 147, in _send
2024-10-01T07:25:38.793180715Z     return sock.send(data)
2024-10-01T07:25:38.793184115Z   File "/opt/python/3.9.19/lib/python3.9/ssl.py", line 1207, in send
2024-10-01T07:25:38.793187615Z     return self._sslobj.write(data)
2024-10-01T07:25:38.793190815Z BrokenPipeError: [Errno 32] Broken pipe

My RCA:

I believe this is due to how Azure's run time is handling multithreading and sockets. If I do head-to-head comparison on how I see threads locally and on Azure, the threads remain much more stagnant, while Azure terminates threads very frequently.

e.g. you can see from above log excerpt that it's already at Thread-14, and locally it hardly crashes.

coming to the main point, the point of failure is below. This part is responsible to write to WSS connection which in this scenario is failed, now when it comes to reconnect the buffer is changed with new Thread-X and it fails due to strict SSL requirements for same buffer for retry attempt.

2024-10-01T07:25:38.793184115Z   File "/opt/python/3.9.19/lib/python3.9/ssl.py", line 1207, in send
2024-10-01T07:25:38.793187615Z     return self._sslobj.write(data)

please check out this as well to enable_multithread==true.

PS:

I don't know if it's your area of support stating the app works locally on windows machine but not on Azure. I would really appreciate your input if least.

Thanks,

Parth

Best reply by PARTH P

I've resolved it now!

the underlying issue was completely different from what error suggested, i.e. Broken Pipe due to socket send operation.

The real reason was intermediate long running operation which I was calling from my incoming message callback function. This resulted into socket IO being hampered, which resulted into thread crashing.

I simply made my operation async and the issue resolved itself. I believe the reason it worked flawlessly on my local is due to 0 latency to the API, but when I deployed on Azure it had to make a network call.

hope this helps,
thanks

View original
2
7 replies