-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
some results sent from reader but missed at backend #15
Comments
Another instance, another log. reader (missed pos = 12? also some log messages appear to be missing, e.g., data received, msg processed for pos = 13,14
web server sees all 15
but app is missing some
|
I don't really know how to interpret these logs, since there is no code that demonstrates how each side works with the WebSocket. But in any case, there is something that is very strange in which it appears that each message is sent on a separate WebSocket connection. When you say that the web server sees 15 messages and you demonstrate by showing 15 WebSocket connections that is wrong, the correct solution would be a single WebSocket connection receiving all the messages. |
All of the code is at https://github.com/louking/tm-csv-connector/tree/e114036e6c024eaae4ad1d26f68788655b45b11b The messages are being sent from tm-csv-connector/tm-reader-client/app.py Lines 134 to 158 in e114036
which would be more efficient, but this was an attempt to fix the lost messages. Following your suggestion of "the correct solution" I guess I could move the connection outside the The receiver is at tm-csv-connector/app/src/tm_csv_connector/websockets_server.py Lines 28 to 44 in e114036
|
Why are you sending like this? while len(queued_msgs) > 0:
async with connect(backenduri) as websocket:
msg = queued_msgs.pop(0)
await send_to_backend(websocket, msg) This is creating a new connection for each message, and it then closes the connection, possibly before giving time for the message to be sent (which I believe happens in a background task). As I said before, I continue to believe this is a bug in your client application, not an issue with Flask-Sock or Flask-SocketIO on the server. |
Ok. I thought the Good input, though, and I'll investigate moving the connect outside the |
Yup, that was it. Thanks for your patience and advice @miguelgrinberg. Fixed with c3da31a |
I meant to note I also needed to use eventlet, else the flask app would get a worker timeout and restart. Possibly this could have been handled with gunicorn threads as well |
see
reader
backend
The text was updated successfully, but these errors were encountered: