From time to time after server reboot, the jdbc adapter is not enabled because the database it is connecting to is not up running yet due to a timing issue.
I am looking for a way to have a process checking if the adapter is enabled and if not enable it automatically.
I know we can use IS’s admin screen to do this, but this requires manual intervention. I need to automate this process of checking and enabling.
Try setting the “Startup Retry Count” and “Startup Backoff Timeout” in the adapter connection configuration to values that will give the DB time to be available.
Thanks. My thinking is this: if it is possible to check/enable automatically, then even in the case of db goes down and comes backup, then I don’t have to worry anymore.
You could schedule a service that you write that checks the status of one or more adapter connections. The pub.art.connection:listAdapterConnections returns the list of connections of a given adapter type. The list includes the status of each connection. You can use other pub.art services to try to enable disabled connections.
But this really shouldn’t be necessary. I’ve never come across an environment where this was needed.
Thanks. But if in the middle of the day db goes down for 10 minutes and then comes back up, your jdbc connection is not going to be reconnected itself, right?
I have never seen it either, but just ned to cover all the possibilities, a lot of money could be lost if it were to happen.
The connection pool minimum size should be 0 to avoid stale connections.
If the DB goes down for 10 minutes, then any integrations that run during that 10 minutes and rely on that DB will fail. And perform whatever error handling you have in place. At this point, the connection pool behavior is (supposed) to empty all connections from the pool and start new connections as they are requested by integrations.
To clarify my “I’ve never seen it happen” comment: I meant I’ve never seen a need to have IS monitor and re-enable connection pools. I’ve seen DB outages happen plenty of times. Your integrations need to be designed to account for that.
For critical connections, use monitoring tools outside of IS to monitor the DB availability.
For integrations that are driven by triggers, you can configure to suspend the trigger on error. Then define a monitoring service that checks the DB connection. Once it is available, IS will resume the trigger when the monitoring service indicates the DB is available.