It happens that the http request already timed out long ago, or that a browser has been closed, but that the query still runs at SQL Server (Azure database instance).
Is there a way to set a database timeout in the Thinkwise database connection settings?
Or should I post this as an idea?
We had some problems during our last update. One of the possible explanations is that something started a query while there were no indexes. Having a reasonable short timeout would protect against this kind of scenarios.
Ideally I would like to set the timeout only for connections from Indicium initiated by the user interface, as updates and DBA work can require longer queries. It would be even better if it would be possible to have different settings per view / workflow step, as queries for normal UI screens should never exceed 1 second, while some graphics / download / upload / update functionalities might require more.
Hey Daan,
Currently Indicium performs the request and sends the response to the client whether or not that client is still listening. Feel free to create an idea for Indicium to ping the listener if it's still actively listening.
Introducing a time-out may have side-effects as some processes simply may take a long time and would be then terminated if it exceeds the time-out period. I'm not so sure this is the best way to stop request prematuely.
I haven’t tried this in a long time. But it was no problem to let Indicium run out of memory without any hassle. Just run a small, fast query that results in a large dataset en tada - it is dead and starts logging out people. Same goes for the odd request where the DB server will eat a boatload of CPU’s and memory (indeed also due to missing indexes for example) for breakfast where the client results in a timeout and re-requests the same (default behaviour of Chrome for example) to just start munching away more CPU’s and memory.
Was looking for a decent mechanism to timeout certain requests. Never found it though.
This is especially relevant when running in Azure as you have a hard HTTP timeout of 4 minutes anyway
@ AndreKemmeren, the problem is not the timeout of the web server. The problem is with the timeouts of the database server after that.
Especially in the 2023 version, it happened that queries never, or 4 minutes later, finished. This is one of my ideas to allow the developer to specify an timeout, and automatically kill things that run to long.
Those long running queries can be both a mistake of the developer or Thinkwise. In both cases a query timeout can make the damage much smaller.
Ok, so I will have to upgrade this to an idea. I believe that it is clear from this discussion that not being able to set timeouts or limits can give problems.
I will upgrade this to an idea, thank you.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.