D
dbeavon
Guest
I just asked this same question a little while ago. It was in the context of the APSV transport but I imagine the same issues apply to REST since it is the underlying ABL client sessions that are having database connectivity problems. Here is the link. PASOE behavior when remote client/server (OE) database is shut down and restarted - Forum - OpenEdge Development - Progress Community Note that the problem was unexpected for me because we've always used shared memory database connections and those simply get recycled when the connection to the database is broken. So for those types of clients, the appserver problems resolve themselves because once the database comes back online, new ABL client sessions are started. However, when you to switch to using OE client/server connectivity, the ABL sessions start generating errors when the database is disconnected. And the errors don't resolve themselves anymore; even if the database comes back online. As far as I know, you definitely need to write your own custom solution to this problem. Here is a KB saying as much: Progress KB - How to reconnect to a database after an error in the AppServer or WebSpeed agent It is unfortunate since every PASOE customer is probably rolling their own solution in their own way. It seemed to me that if the database connection parameters are specified in on the agent at startup, then that is a necessary prerequisite for application code. And it should be PASOE's responsibility to make sure that the agent is cycled when the database is shut down. Here is my solution (very different than the one in the KB). I wanted the problem to be solved in a generic way that was external to the custom ABL code running within PASOE. So I created to health-monitoring methods, one that has no database access and returns a response of TRUE, (HealthCheckupWithoutDataAccess) and the other that reads a single record from the database (HealthCheckupWithDataAccess). Make sure they are both fast and not resource-intensive (< 50 ms end-to-end). The goal is to bring PASOE back online as soon as possible after the database comes back online (for me I wanted it to be under one minute). So each minute I do as follows in my own cron/service/job/whatever. STEP 0 : Enumerate all agent processes and sessions for the ABL Application using the REST API (OE Manager). If there are no sessions at all then do nothing. (see STEP 2 for more on the OE Manager) STEP 1 : Get the result from both HealthCheckup methods that I described above. If the one with *no* data access works but the one *with* data access generates an error, then I know that my agents are being affected by a database outage. STEP 2 : If I'm affected by an outage then enumerate all agent processes for the ABL application and delete the sessions of each (see PAS - Pick up new r-code - Forum - OpenEdge Development - Progress Community for details. Make sure to use the powershell script that deletes sessions for a given agent: IE. Invoke-RestMethod -Method Delete -Uri (hddp://localhost:' + $portnumber.ToString() + '/oemanager/applications/' + $ablapp + '/' + $agent.agentId + '/sessions') Yes, this is a lot more effort than it should be. The nice thing is that I don't have to clutter my ABL with any reconnection logic. Hopefully one day PASOE will do some of this work itself.
Continue reading...
Continue reading...