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.
Execution_Contexts - one mother's story
Execution_Contexts - one mother's story
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
MySQL, AWS EC2, S3
PDFtk Toolkit
Re: Execution_Contexts - one mother's story
If port 9000 is accessed by another application while AIM is running, then AIM loses the port and goes into a spin.The only way to resolve this is a reboot. Its very possible for this to happen , either by other programs running on the server that periodically connect to this port or an inbound hacking connection attempt if the port is open to the public. All it needs is a brief connection by another process and then AIM is gone.Logon attempts were greeted with a TCP Port 9000 error
I believe this is major source of all problems when suddenly users cannot login anymore.
There is an update (not sure which version)where there is reference to better port handling, so i am assuming it has something to do with this. If you are on an older AIM version this problem will prevail
Re: Execution_Contexts - one mother's story
That's why I always change AIM port 9000 to other port number to prevent the issue.
Regards,
Suwandy
-----------------
Kisaran - Indonesia
Suwandy
-----------------
Kisaran - Indonesia
Re: Execution_Contexts - one mother's story
I'll also change to a non-9000 port.
But then when something DOES crap out Magic (I've traced this to a hacker hitting the server, and seen this recently in the past month also), I've found a slight delay in restarting because it will say something has port 9000.
For me, it takes a few mins for that port to get released.
I can see it busy by multiple connections (most likely my valid connections from users that were logged in).
Sometimes I bump it 1 # (like 9000 goes to 9001) cause no one will be on that port and I need to get the system back up quickly.
But then when something DOES crap out Magic (I've traced this to a hacker hitting the server, and seen this recently in the past month also), I've found a slight delay in restarting because it will say something has port 9000.
For me, it takes a few mins for that port to get released.
I can see it busy by multiple connections (most likely my valid connections from users that were logged in).
Sometimes I bump it 1 # (like 9000 goes to 9001) cause no one will be on that port and I need to get the system back up quickly.
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.
Jaymer
Aware Programming & Consulting - Tampa FL
Jaymer
Aware Programming & Consulting - Tampa FL