D
dbeavon
Guest
I have a windows service on the PASOE server that detects the health of the entire PASOE-ABL-application by polling two separate methods every thirty seconds. The first method runs a simple ABL statement that does *NOT* interact with the database. The second statement runs a simple ABL statement that does interact with the database. Since I want to isolate database connectivity issues, I only take action when the first method is succeeding for a given ABL-app and the second is failing. I don't care about any other variations. This indicates that there is a problem, and one that is connectivity-related. When these facts are established, then the health service will simply trim all ABL sessions for the ABL-application using the oemanager REST interface. By doing so, it will flush out the ABL sessions that have are affected by latent connectivity problems (but may not even know that yet). One final rule for the health monitoring is that, before the two methods are called, you have to query the oemanager REST interface to determine the number of ABL sessions in the ABL application (for all agents of the application). If there are absolutely no sessions, then there is nothing that needs to be done (during that thirty-second-iteration). Without this rule, then the polling methods themselves may do more harm than good (ie. if there are ongoing/intentional/planned outages). Hope this is clear. Personally I think all this work should be unnecessary, especially given that PASOE can now detected "externally instigated db disconnect"... MSAS Destroying Session AS-4 due to externally instigated db disconnect ... in other words, PASOE should at least take the initiative to trim the other ABL sessions in the same ABL application so that the others don't continue to have the latent connectivity problems as well. Otherwise the problems in these sessions drag on for a much longer period of time than necessary.
Continue reading...
Continue reading...