-
-
Notifications
You must be signed in to change notification settings - Fork 54
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
SocketIO: Lots of panics on unwrap in case of there are lots of clients #27
Comments
Iit is weird that there are poisoned locks because locks appear only in the If it works with dashmap without too much overhead we could try to switch |
my logs was a consequence, not an error |
Ah ! You found the real issue :). We need to fix the TODO by mapping the error to the returned Result rather than unwrapping. |
Also it's related to my client example, it tries to send 10000 messages asynchronously, but default buffer of packets only 128, when I limited clients to send no more than 120 messages - all was good. I will return error instead of unwrap, but actually we should think how to handle it correctly: |
Yes, the best would be to have an error type with a generic that returns the message sent in case of error. Like in the channel errors. It would imply to create a new enum |
error:
How to reproduce:
run socketio server(i used main)
cargo run --release --bin socketioxide-e2e
run js clients client.zip
For me it reproduces even with 100 clients.
also I locally tried to replace RWlock to Dashmap and errors dissappear
The text was updated successfully, but these errors were encountered: