Resolved Out of resource issue in Progress 8.3C version

Sowmya11

New Member
Hi,

We have a progress database 8.3c version which we access using both CUI and GUI.
Start up parameter detail : -n 10 -Mn 6 -Ma 1 -Mi 1 which means we can have 6 GUI connections ( 6 servers and 1 user per server making 6 * 1 = 6 ). On every 6th or 7th and 20th of a month all server connections throw the following error:

08:36:46 SRV 2: Server's received count 1 does not equal client(1)'s send count 1414744096. (1055)

Error History:
Sun Jan 6 2013
Sun Jan 20 2013
Wed Feb 6 2013
Wed Feb 20 2013
Thu Mar 7 2013
Wed Mar 20 2013
Sun Apr 7 2013


And server status in Promon (Enter your selection: R&D -> 1. Status Displays ... -> 3. Servers) shows following readings under Cur user: (weird negative numbers)
Sv Cur. Max. Port
No Pid Type Protocol Logins Users Users Num
0 9224 Login TCP 0 0 1 20500
1 12718 Auto TCP 373 -49 1 1026
2 12720 Auto TCP 83 -50 1 1029
3 12727 Auto TCP 54 -49 1 1031
4 12734 Auto TCP 29 -48 1 1035
5 12748 Auto TCP 28 -48 1 1046
6 12762 Auto TCP 64 -49 1 1053
In such conditions users are not able to make remote connections (GUI). Restarting the database resolves the issue but we do not know the root cause for this.
Please let us know your suggestions to resolve this. Thanks in advance for the help :)
Best Regards !
Sowmya
 

RealHeavyDude

Well-Known Member
I once had exactly the same issue with an OE10.1c database. The database broker recognized the individual servers as available but still the individual servers ( or ports ) were occupied by "something" else. Progress TechSupport had no explanation for that behavior - therefore it looked like we were searching a needle in a haystack. In the end it turned out to be a port scanning software running against our database machines trying to find security breaches that caused that weird behavior on the remote servers. Don't know whether you are facing the same ...

In the end we changed the -minport and -maxport settings so that the broker starts the remote servers in a "save" port range and the problem went away as fast as it came.

Heavy Regards, RealHeavyDude.

By the way, 8.3c is pre-Stone Age software ...
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I've experienced several bugs when allowing Progress to select server ports in its default range. For 4GL servers it won't use ports that are defined in services, even if they're not in use. I've even seen a broker try to give the same port to two different servers! I always specify -minport/-maxport on my brokers.
 

TomBascom

Curmudgeon
08:36:46 SRV 2: Server's received count 1 does not equal client(1)'s send count 1414744096. (1055)

Which part is always the same? Just the error number? Or the 1,414,744,096 as well?

Where does "out of resources" come in to play? That's mentioned in the title but not the message body.

Best practices:

0) Run up to date releases of software. 8.3c is not even remotely up to date. Are you still running it on Windows for Workgroups? No? Why was it ok to upgrade Windows but not Progress?

1) Always set -n much higher than it "needs" to be. In your case -n 30 would not be inappropriate. (-n is connections, not licenses -- the two are not related).

2) Always use -minport and -maxport. And make sure that the selected range has spare room and no conflicts.
 

Sowmya11

New Member
Thank you all for your prompt replies.

Hi Tom, It's always the same error including this number 1,414,744,096 .
Due these conditions users don't get GUI sessions and get error "Out of resource" hence mentioned the same. (the issue that users report to us)

This cannot be port issue because when we start the database itself ports are allocated to server processes (please check in promon reading given above). Once allocated they cannot be interrupted by other processes. In this case the server processes seem to get corrupted eventually not allowing db connections. Please let me know your veiws on this.
 

TomBascom

Curmudgeon
Since the number is always the same my guess is that you are hitting a "magic number". It's probably a bug.

8.3 being of pre-historic vintage and all your best bet is to upgrade to something modern. Like 11.2.
 

dulecki

Member
And since this is an 8.3 Progress version, remember that way back then, there was an issue if the number of connections to the database reached -n. No new connections could be made until the database was rebooted. This has since been fixed, but I don't remember exactly when.

Another reason to increase -n or move to a more current version of Progress, as Tom suggested.
 

Sowmya11

New Member
Thank you Tom :)

Hi Dulecki, thank you for the info :) you said the issue was fixed but don't remember when. Could you please let me know how it was fixed ?
 

dulecki

Member
You're welcome.

As to how it was fixed, Progress made changes internally to the Progress product. Upgrading to a more current version of Progress (at least 9.1E, but preferably 11.x) will get you the fix; until you get it, make sure your total number of connections does not hit -n.
 
Top