Failure Reading response from Application Server

A

Akhil

New Member
Hi everyone,

I am running a remote procedure by establishing an appserver connection. The program works perfectly fine and returns the results after executing the program in the remote session.

However, sometimes it returns a message "Failure reading response from Application Server" and then the program execution terminates at this point. I tried to debug this and and found that my program was able to establish an appserver connection.

Can anyone help me figure out why this message comes up and how to handle this ?

Thanks & Regards,
Akhil
 
You define it when you configure the AppServers via the Admin Service ( or manually in the ubroker.properties file that usually resides in the properties sub directory of the installation directory ). Look out for the brokerLogFile and srvrLogFile properties in the section for your AppServer instance.

You don't tell anything about your Progress/OpenEdge version. Depending on the version you should probably think leaving the connection to the AppServer (when it is state-less) and only disconnect when you are done with your runs.

Heavy Regards, RealHeavyDude.
 
I found the log file and could see many warning messages being generated into that file such as "WARNING: -l exceeded. Automatically increasing from 350 to 360. ".
After many iterations of the warning messages above, it then gives the following error

SYSTEM ERROR: Attempt to define too many indexes for area 6 database DBI200882944aXiDUC. (40)
** Save file named core for analysis by Progress Software Corporation. (439)

Any breakthrough on this ?

Any yes, I am using open edge version 10.2B
 
The warnings are not, in themselves, a problem but they might be leading up to the "too many indexes" error. That means that you are creating temp-tables but not removing them on your app server. Possibly by way of dynamic statements or alternatively by creating persistent procedures and not cleaning those up.
 
Judging by the fact that it runs ok locally (not a 100% cast-iron test), I'd have thought looking at stuff not being cleaned up on the AppServer as being the most likely cause.
 
As a best practice I include the "CREATE WIDGET-POOL NO-ERROR." statement at the top of each procedure that runs on the AppServer. That way all dynamic handle-based objects that get created on the way are ending up in the unnamed widget pool scoped to that procedure. That way it is ensured that all theses dynamic objects are cleaned up properly when the procedure goes out of scope - unless somebody created such a dynamic object in a named persistent widget pool on purpose. I try to avaoid persistent procedures on the AppServer as much as possible for that reason. Nevertheless, another best practice - You create it, you delete it - served me very well.

Heavy Regards, RealHeavyDude.
 
I could resolve the issue by adding "-reusableObjects 0" in the session startup parameter of Open edge 10.2B. This ensured that the "-1" memory didn't pile up with each connection.

Thanks everyone for your advice.
 
You must log in or register to reply here.
Back
Top