gmantele
commented
6 years ago That's exactly the purpose of the property max_async_jobs. It defines the maximum number of running asynchronous queries ; if more are requested they will be queued.
By default, it is set to unlimited. But if you know your DB connection pool offers N connections maximum, set this property to N-M, M being the number of synchronous queries you want if all the N-M asynchronous queries are running in the same time.
Let's say you want maximum 5 asynchronous queries running simultaneously, you will still have 5 DB connections available for synchronous queries, if you set max_async_jobs to 5 and that your DB connection pool is limited to 10 connections.
Of course, as I said above, when someone submits a new asynchronous query while already 5 are running, his query will be queued (i.e. it will be executed only when one of the 5 running async queries finishes).
If the max number of connections to the database has been reached, no new /sync query can succeed. In my case, I have now 10 connections taken by 10 /async jobs, and given that 10 is the max number of connections defined in the connection pool, any new /sync query returns an error.
Given that /sync queries are supposed to be light and quick, I would think that they should be executed no matter how many /async jobs are active.
Is there a way to configure TAPLIB to obtain this?