I want to pass on this story for the good of all mankind.
I updated my BSV by changing one word in a notification. A low-risk deployment. I have a script that triggers a server restart when I want to deploy by placing the BSV in the Auto_deployment folder and set the clock to trigger it. On this occasion, I woke up to find the server dead. Logon attempts were greeted with a TCP Port 9000 error. The BSV was not deployed and the Java server was crashed out. I triggered the server restart again with the same results. I removed the BSV file from the Auto_Deployment folder and restarted it again. Mind you, I am starting the services from a batch script.
As I recall, this worked on the second attempt. For operational reasons, I walked away with the system running and set up a maintenance window. What I later found out by attempting a deployment using the Control Panel (I could/should have looked at the wrapper logs), was a Java Heap error during startup.
A couple of years ago, my runtime client suffered some data corruption in one of the system tables, probably the one that holds the BSVs. So, my thinking was that this might be a similar corruption and the deployment won't store the BSV and is making the Java Heap go nuts. This was my top theory.
Then I remembered the Execution_Contexts table. I looked at it and noted 880 rows. I then went to the app and looked at Active Processes. Doing so failed and the browser presented an error "Custom Error" - go figure. So this got me thinking I should clear that table out. It's a known good practice to do so every so often and there are other tales here about problems that this table can cause. These records don't timestamp, so there's no way of looking at the history from a time standpoint.
So that fixed it. I don't routinely clear that table. I might have done it once before in over 10 years. Might do it more often, I think.
