What are we optimizing?
Based on previous experiences and to further ensure the service’s stability and performance for all users, we are introducing an extension to our Read Ticket Management. We want to make sure that your subscription does not get overloaded with incoming query requests by single users, and that other users do not have to wait endlessly.
What is the current behavior?
If more query requests need to be executed than Read Tickets are available, the query request gets queued to wait for the next free Read Ticket. This can lead to the problem that one user can still occupy the whole queue by spoofing requests for a long period of time. This can block all other users and operations in the related project (subscription).
What is the change?
Each Read Ticket now comes with the possibility to queue 5 query requests. That means, if you have 3 Read Tickets booked, 15 query requests can be queued. We also added the new query status QUEUE_FULL which lets you know when there are too many query requests that have to be processed in parallel. Further query requests will not be added to the queue then. This way it is ensured that a single user cannot occupy the queue endlessly and other users still have access to the subscription data.
It ensures the stability of your database to prevent blocking states for your subscription.