Jiwa

We have a client who is running the api against Azure SQL and the api sometimes drops its connection to the database, a service restart fixes the issue and I have already increased the timeout, Jiwa itself goes on quite happily from the same Azure vm which I suspect is due to its baked in redundancy to reconnect itself, in having a quick look at ORMLite under the hood it appears it's using the same technology, so my question is there a simple way to add the same sort of redundancy to the api like Jiwa has?

SBarnes wrote:We have a client who is running the api against Azure SQL and the api sometimes drops its connection to the database, a service restart fixes the issue and I have already increased the timeout, Jiwa itself goes on quite happily from the same Azure vm which I suspect is due to its baked in redundancy to reconnect itself, in having a quick look at ORMLite under the hood it appears it's using the same technology, so my question is there a simple way to add the same sort of redundancy to the api like Jiwa has?

The connection resilience and transaction fault tolerance the Jiwa application enjoys would still apply to the REST API. For the operations which are backed by Jiwa business logic, these all use the same database layer as the Jiwa application - so the behaviour and capabilities are exactly the same.

I've logged DEV-8770 to test and see if we can find an issue and if so, provide a fix or work-around.

The line it fails on is definitely directly ORMLite related as its when it gets records from SY_WebhookMessages

If the symptom was this error:

Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

Then I believe this was fixed with DEV-9205.

Our Webhooks and a few other parts of the REST API plugin were using OrmLite and not correctly disposing of the connection - resulting in the pool being exhausted in some circumstances.