i have a gateway script that stops in a middle probably due to a jdbc connection failure on a database. There is no log associated with this error and the database is valid. So the only thing is to restart the script which I can do manually, but I would like to do this automatically.
I have set the Scripting.ScriptManager to TRACE.
Restarted the gateway, and I already know that the jdbc driver will fail due to a bad internet connectivity and this will not help at all. I will still need to restart the gateway script manually, what about automatically?
There might be simpler ways, but I’ve handled vaguely similar issues by having the script use memory tags to record it’s current state and/or a timestamp of when it passed certain checkpoints. You can then have another tag change or timed gateway event which looks at those tags and decides if things went wrong and how to respond.
You cannot. You should write your code as a state machine and call it regularly (timer event) to act (or not) upon current conditions. You almost certainly need to catch your own exceptions–the ScriptManager’s logging points won’t help you debug your code.
Not sure I understand this.
What is a state machine?
If the script manager logging is not the help I need, what is the log I need to find out why the Gateway event script is stopped? I know that it is stopped because the jdbc cannot reach the database because of the internet connection that is not reliable. But it still would be nice to catch the log information.
For our purposes, it is a piece of code that follows a series of steps (states), where the actions it takes and conditions it checks depend on the step (state) it is in. Sequential Function Charts are a popular formal way to do state machines but they can be done in any language. The point is that you write code that looks at a persistent variable (memory tag, perhaps) that says “I’m in step 5” and the code does the next action for step 5, then decides if it achieved step 6, or stays in 5, or goes back to 4. Or whatever.
The code checks its state every time it runs (and it is made to run regularly) and acts accordingly. In your case, you have at least the following steps:
Start. Haven’t done anything yet. Probably should try to connect.
Connecting in progress. Waiting for connection or timeout or error.
Connected. Can do operations with connection.
Timed out or errored. Log it, wait a bit perhaps, then back to step 1.
Anyways, your code must capture the errors and update the state appropriately. There isn’t any logger that will tell you why your code died.