-
Notifications
You must be signed in to change notification settings - Fork 126
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
Handling long-running operations #135
Comments
Hey @Hulkstance , good question, but it really depends on your usecase. After answering, you can choose the solution that best fits your problem. In my recent projects, I usually wanted to process messages one by one and keep the system safe against any server overflooding, so I went with Channels. One example here - Nostr bot, although here I went with unbounded because there is a low chance of being overflooded. Also, I want to process every message even though it can slow down the overall bot reaction. |
@Marfusios, thank you for your insights! Messages can definitely be processed in parallel because the order of the messages is not important as I've built a wrapper that matches each request with its response using IDs. This needs to happen quickly due to a strict timeout for catching responses. Missing messages is not an option, as the system will run out of sync with the exchange, and would have to fallback to REST for re-synchronization. But maybe at some point the order of the messages does matter since there is a logon, logoff and session reconnection on server side. Talking about CQG btw. |
If a message takes 5 seconds to be processed as it involves some database operations, it shouldn't slow the server processing pipeline overall as that's going to cause backpressure. In such situations I really wonder what @Marfusios you would do:
instead of
What do you think is best? Both solutions are working but I kinda want to know someone else's opinion.
The text was updated successfully, but these errors were encountered: