Monitoring (and removing) old sessions

[dlangschied]

I have always had an issue where old database connections linger. They are connected to the database, but no longer running the application. Watch Dog does not seem to do anything to help the situation. I would like to get a workable solution to cleaning these connections up. Recently, we moved to a remote only environment (previously, almost all self) and now the number of these connections has risen. I clean up daily, but I want Progress to do the clean up.

We are running QAD eB2.1SP4 on OE10.1CSP2 on Redhat Linux 6.4 (Santiago).

Thanks!

 

[Rob Fitzpatrick]

If you're clients are all remote then the watchdog process won't do what you want, by design. It cleans up dead self-service clients, or remote servers, but not remote clients.

What is the state of these "lingering" clients? Has the client process died, and you are waiting for the TCP keepalive timer to expire on the socket, or is the client process still running?

 

[Cringer]

Is it possible it's a code issue that something isn't cleaning up properly on shut-down?

 

[dlangschied]

I do not really have an answer to your question. The code that is launched on the application server is still running, but the user has long since been disconnected. I have not been able to really get to the bottom of it. People do get disconnected from time to time via our telnet application. The application used to be on the database server. We moved the databases to a new server to alleviate processing time issues. The fact is that now all users are now connecting remotely where as before most connections were local. This has caused an increase in these sessions due to WDOG not being able to see those sessions as disconnected. I have always wanted some better way performing this cleanup when it was a very small number of sessions, but cleanup was only necessary on a monthly basis. I figured I would throw the question out there as I am preforming daily cleanup and that is not good going forward.

 

[TomBascom]

Perhaps if you described in some detail what it is that you look at to determine that something needs "cleanup" and then what actions you take to effect that "cleanup" we might have more concrete suggestions to offer.

 

[dlangschied]

I "cleanup" on Tuesday noon any user sessions from Monday, since all users who have logins that are more than 12 hours old have left for the day (and probably returned). I guess the short answer to the problem is to know which sessions these are and be able to disconnect them from the command line. Currently, I use promon, which is time consuming and has the potential to cause the inadvertent disconnect of an active user (though this has NEVER happened with me).

 

[TomBascom]

This is still far too vague for me.

What specific screens to you go to? (Provide bread crumbs through the menus or I will be back again asking for details...) What particular metrics on those screens do you look at? What values are good? What values are bad? When you see something bad what is the complete, detailed and specific sequence of actions that you then take? Is there an exception process? (IOW if your first attempt to cleanup doesn't work is there something else that you do?)

 

[dlangschied]

Sorry for the delay.
To clarify,
The application is QAD eB2.1 SP4 (server A).
The Progress version is 10.1C SP2 (server A for 4GL; server B for database).
The Linux version is RHEL 6.4 (Server A and B).

The user connects on server A on Monday. After some time, the user is still connected using mpro process on server A and database connection on server B, but the user is no longer connected via telnet session (left with session running, went home and got disconnected or something akin to that). On Tuesday, I go into promon and run menu 8. I disconnect Monday's sessions since they are no longer active. This takes about 15 minutes for the 4 databases to which the users connect.

I would be better off performing a linux kill, but I am reluctant to do so. I am asking the gurus out here for a Progress Administration approach that is better suited for this situation.

Regards,
David Langschied

 

[TomBascom]

That remains incredibly vague.