No more resources when Disconnect a user

[joelbm30]

Hi, I hope somebody can help me with this issue...



Progress 9.1e Workgroup
Windows Server 2008
14 users

5 data bases with this startup parameters:
-n 60 -Mn 5 -Ma 12 -Mpb1 -H VeroSvr -S Gsadmi -N TCP -ServerType 4GL

also, I have a secondary broker for each db :
-m3 -Ma 2 -Mpb1 -H VeroSvr -S Gsadmi -N TCP -ServerType SQL

When the user db licenses (14 users) are saturate, sometimes a user lose their network connection but the user are not released and remain taking a user license... I use the PROMON dbname utility to disconnect that user, but after the user are disconnected, the user licenses are still saturated... and that user or another can't connect to the database...


Somebody knows how to resolve this problem?


I will appreciate very much you help.


Thanks.

 

[tamhas]

Are you running watchdog?

 

[joelbm30]

[FONT=&quot]Hi tamhas,

I'm not using watchdog, but, I read that PROWDOG enables you to restart a dead secondary broker without shutting down the database server[/FONT] [FONT=&quot][/FONT]. It will work for any server? not only secondary?...

I also read this:
The Watchdog cannot detect lost remote clients because remote clients are not associated
with a process. Instead, a network protocol timeout mechanism notifies the server that the
network connection was lost.

I never have been use watchdog... and i have a few doubts, Do you recommend that watchdog need to be running always? or only when you need it as in my problem? In general, how do you use it?

Thanks for your reply.

 

[RealHeavyDude]

Somebody correct me, but, AFAIK when remote clients disappear the broker might not know it until the TCP keep alive has timed out, which, AFAIK, is 30 minutes on most systems. Therefore it might take around 30 minutes until the broker cleans up a disappeared remote client.

Self-service clients do not connect via TCP, instead they connect directly via shared memory. When such clients disappear the watch dog will free up the resources occupied by these clients. Having the watch dog running is always recommended as soon as you have self-service clients connecting to your database.

Regards, RealHeavyDude.

 

[joelbm30]

[FONT=&quot]Hi RealHeavyDude,

Since my connection mode isn't a self-service client... with remote clients, the watchdog can't resolve my problem?

Do I always need to wait about 30 minutes [/FONT] [FONT=&quot]until the broker cleans up a disappeared remote client?

Thanks for your reply...

Regards.
[/FONT]

 

[joelbm30]

Tomorrow, I wil connect to my customer server, who has this problem... I will activate watchdog and I hope it works for me, after that I will tell you the result with this issue...

 

[RealHeavyDude]

Yes, the watchdog will only free up resources blocked by self-service client which did not gracefully disconnect from the database.

The TCP keep alive setting is the maximum time until the database should recognize a disappeared remote client. I deliberately said should. I've seen occasions where disappeared remote clients locked resources until the database broker was shut down. But as far as I remember I've only seen that behavior in Progress V9 with the database running on Windows.

Regards, RealHeavyDude.

 

[joelbm30]

Thank you very much, I understand much better this problem... I will working on that, and too, I will recommend to my client that upgrade his progress version.

 

[Cecil Snodgrass]

RHD is correct about the tcp keepalive, by default it is 2hrs on Windows (7,200,000 milliseconds), take a look at \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters in the registry

 

[joelbm30]

Hi Cecil, I have been reading about that....

I found this doc from microsoft:

KeepAliveTime

Key: Tcpip\Parameters
Value Type: REG_DWORD—time in milliseconds
Valid Range: 1–0xFFFFFFFF
Default: 7,200,000 (two hours)
Description: This value controls how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. If the remote system is still reachable and functioning, it acknowledges the keep-alive transmission. Keep-alive packets are not sent by default. This feature may be enabled on a connection by an application.


In the description, tells that Keep-alive packets are not sent by default and this feature may be enabled on a connection by an application (I guess progress app)...


But How do I enable the keepalive function on progress?

 

[joelbm30]

I found this fix at the progress knowledge base

ID: P3523
Title: "TCP port remains in use forever when the socket client has disappeared"
Fixes:
Turn the KeepAlive mechanism on with:

hSocket:SET-SOCKET-OPTION("SO-KEEPALIVE","TRUE").
For socket objects created using CREATE SOCKET, the default of SO-KEEPALIVE is FALSE. For socket objects created by Progress and passed as a parameter to the event-procedure context, the default is on.

Notes:
The SO-KEEPALIVE option for the SET-SOCKET-OPTION() method has been implemented in 9.1D, so this fix cannot be applied with earlier versions.

But I don't understand if I must run a procedure with hSocket:SET-SOCKET-OPTION("SO-KEEPALIVE","TRUE") instruction at the server where I have muy database, Is enough to run this procedure only one time and remains the keepalive option with a true value?

 

[Cecil Snodgrass]

You just need to set the keepalive time to a small value, 1-10 minutes for example. This is actually opposite of of an application keep alive, turning on keepalive in a application such a a terminal emulator, will keep an application running if there is no keyboard activity for a given length of time. You want a small tcp keepalive value to terminate dead connections quicker that the 2 hr default. (if it's enabled at all). It will also take care of the stranded clients if you have a network outage someplace.

 

[joelbm30]

thanks Cecil, I'm going to make some testing with this options.