You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 18, 2021. It is now read-only.
It's pretty easy for a user to basically break the server by e.g. zooming out a lot. I think the main reason is that there's no limitation on the number of pending queries to the DB, which means that they will queue up and the server will have too much to do for a long time, possibly also running out of memory.
Not sure what's the best way to deal with this. Perhaps simply keeping track of each user session to prevent queuing up new queries until the previous one completed. This is not quite trivial since it's important that the user at least eventually gets the latest data requested. Maybe keeping track of the "current" and the "latest" request per user session, and whenever the "current" is complete, if no "latest" request exists we return the result, otherwise discard it and process the "latest". If a new request comes in before the "current" request is completed, we just replace the "latest" with the new. As far as I can tell, it's not really possible to manually abort a Cassandra query that is already running in the cluster.
The text was updated successfully, but these errors were encountered:
It's pretty easy for a user to basically break the server by e.g. zooming out a lot. I think the main reason is that there's no limitation on the number of pending queries to the DB, which means that they will queue up and the server will have too much to do for a long time, possibly also running out of memory.
Not sure what's the best way to deal with this. Perhaps simply keeping track of each user session to prevent queuing up new queries until the previous one completed. This is not quite trivial since it's important that the user at least eventually gets the latest data requested. Maybe keeping track of the "current" and the "latest" request per user session, and whenever the "current" is complete, if no "latest" request exists we return the result, otherwise discard it and process the "latest". If a new request comes in before the "current" request is completed, we just replace the "latest" with the new. As far as I can tell, it's not really possible to manually abort a Cassandra query that is already running in the cluster.
The text was updated successfully, but these errors were encountered: