Execution_Contexts - one mother's story

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
Post Reply
kklosson
Posts: 1617
Joined: Sun Nov 23, 2008 3:19 pm
Location: Virginia

Execution_Contexts - one mother's story

Post by kklosson »

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.
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
ACDC
Posts: 1138
Joined: Sat Jun 30, 2007 5:03 pm
Location: California, USA

Re: Execution_Contexts - one mother's story

Post by ACDC »

Logon attempts were greeted with a TCP Port 9000 error
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.

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
cishpix
Posts: 183
Joined: Fri Nov 06, 2015 5:07 am
Location: Indonesia

Re: Execution_Contexts - one mother's story

Post by cishpix »

ACDC wrote: Sun Jul 11, 2021 9:06 am If port 9000 is accessed by another application while AIM is running, then AIM loses the port and goes into a spin.
That's why I always change AIM port 9000 to other port number to prevent the issue.
Regards,

Suwandy
-----------------
Kisaran - Indonesia
Jaymer
Posts: 2430
Joined: Tue Jan 13, 2015 10:58 am
Location: Tampa, FL
Contact:

Re: Execution_Contexts - one mother's story

Post by Jaymer »

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.
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
Post Reply