Our client runs their character (host-based) application in the cloud. Users acces it with Putty. A network hickup causes the user to lose control of their session. We have to kill the session if it has a record locked. I thought that the watchdog would cleanup such sessions but it appears not so. Is there another option for these kinds of sessions to end without having to reside to root killing the proces?
In environments where the host OS supports it, I absolutely swear by terminal multiplexing applications. For Linux hosts, this can be "screen" or "tmux". You can configure the application client scripts to detect if there are any detached sessions and reconnect, or in the absence of those, merely start a new multiplexed session.
This way during a network 'hickup' or even straight-up disconnect the TTY client session will remain connected.
You don't mention the host OS, I am guessing Linux/unix from your reference to root. I am a little rusty on watchdog, but I think it only cleans up if it detects the client process has terminated. In this case, it seems the network hiccup has not (yet) resulted in a hangup, so the process continues running. IIRC, this is related to TCP keepalive, and reducing the keepalive timeout might help the process terminate faster.
I am not aware of what might be available in PROMON for this. There is an option to disconnect a user, but I don't remember the consequences of this in the circumstances you describe. Maybe others who are more current on this can assist.
On the top of what Garry said w.r to keepalive, also decrease tcp_retries2.
default timeout for keepalive is about 2.5 hours. many folks make it lower (on the server side).
regards, knower of even more obscure things.
gus
I’d tell you a UDP joke, but you might not get it.
In environments where the host OS supports it, I absolutely swear by terminal multiplexing applications. For Linux hosts, this can be "screen" or "tmux". You can configure the application client scripts to detect if there are any detached sessions and reconnect, or in the absence of those, merely start a new multiplexed session.
This way during a network 'hickup' or even straight-up disconnect the TTY client session will remain connected.
So the DB is running in the cloud but the Putty sessions are running locally to the users?
If that is the case you should look into tmux as suggested by chthomso. Life will be easier for everyone involved and if they lose their sessions they can just reconnect where they were.
Other options would be a terminal server/citrix in the cloud but you could put tmux in place without the users having to do anything (just fix the login scripts).
Thanks chthomso and Bronco who suggested it offline. Our non Progress Linux system administrator said he could do is with tmux.
Hi chthomso,
We're having a little problem to conifgure screen correctly. And according to our sysadmin tmux doen't work with our OpenEdge application.
We can't get the codepage correct. In Putty we set translation to ISO8859-1 and I'm pretty sure that's the codepage we use in the application. Any suggestions or tips?
We're running 64-bit OE11.4 on CentOS (I believe 6).
Correction application settings are cpinterrnal is IBM437 and cpstream IBM850
Richard
What reason does the sysadmin give for tmux not working with OpenEdge? tmux works at a much lower level that doesn't know anything about OpenEdge... or Oracle... or whatever is beyond handing the tty sessions.
For the codepage you would want to set the putty codepage to IBM850 (aka CP 850, IBM 00850,OEM 850,MS-DOS Latin 1). Windows-1252 might also work.