We have an application running some complex dialogue manager and several table requests. This always returns a complete HTML to the browse. But, about one time in a dozen, the agent on the server continue to run or crashes. This difference in behavior happens even when the exact same application processing is happening.

The HTML page returned to the browse even contains the ending comments

< !-- [time 122959) -->
< !-- CGI gened on Dec 8 2004 18:30:00


We are under the assumption, the thread clean up process is failing when closing the agent.. Does any one have any ideas why the agent clean up process is not always working properly?


WebFocus 5.5.3 running under Windows Server 2003 and CGI

Hi Jim,

We had the same problem. Here's a copy of some of our edaserve.cfg
We had to move the location of our agent_refresh and crashed_cleanup = on to get the agents to clean up properly.

Hope this helps and hope all is well!

Carol


approot = D:\ibi\apps
server_name = "WebFOCUS 52 Server"
edaprfu = D:\ibi\profiles
cfg_date = 05/21/2003 16:52:22
crashed_cleanup = on
SERVICE = DEFAULT
BEGIN
maximum = 40
number_ready = 20
cpu_limit = 360
agent_refresh = 40
END
SERVICE = WC_DEFAULT
BEGIN
maximum = 2
number_ready = 1
END
SERVICE = DFM_DEFAULT
BEGIN
maximum = 10
number_ready = 1
END
mss_access = y
mac_access = y
odbc_access = y
server_admin_email = bkeene@babsoncapital.com
edatemp = d:\ibi\edatemp
ora_access = y
ora_rel = 9

Carol:

Thank you. Am I correct in inferring you never did determine the root cause of crashed agents?

We seem have one in thirty-odd crash, of the processor with complex dialogue manager. By complex I mean one of the –INCLUDES is 730 lines of DM, with a triple nested loop and plus two simple loops all using subscripted variables.

It appears failure rate gets worse when we have a “–SET &ECHO=ALL;” active. But, in all cases the “Browser” gets no error messages.

I am wondering if the agent is corrupted by a prior use. I have found a note in

61161063 : KNOWNPROBLEM - ACROSS values are not appearing on the report. - Information Builders

with is about WebFocus Major Release: 431

“This actually corrupts the agent (unless agent refresh is set to 1) so all subsequent request present this problem.”

This indicates that the agent initialization for reentry is not perfect. Quite a while ago, I suffered from flaws in the clean up / initialization when doing real time programming under IMS.

Jim

Hi Jim,

We never determined exactly what code was crashing the agents, mostly users writing bad code. But we learned that the Crashed Cleanup command needed to be outside the SERVICES block of code. It was previously inside and the agents never cleared. Once we moved it up before the SERVICES, each agent recycled correctly no matter what was being run.

Sorry, it sounds like you're up against something more difficult (still keeping things simple, huh?)

I don't know about the agent refresh being set to 1, I'll have to look into that.

Carol

I have been having a **** of a time with crashing agents but in my case the problem has been identified, and if not solved there's a workaround. In my case it's the use of vchar fields in FML reports, and it's a doozy.

When running FML report, the following causes an agent crash (I'm using Wintel 7.1.3):

If the report contains a RECAP -and- uses a vchar field -and- any field is "<" referenced in the header or footer... *bang*. No field in the header? It works. No vchars? It works. No recaps? It works. All three at the same time? Kablooie. Took me days to figure that out and the helpdesk came up with it about the same time I did.

One workaround is to "clone" the fields with a DEFINE to a fixed length field. This works until you use the report in PDF Layout Painter, when it all falls apart again. The only fix is to twiddle the MAS usage type to fixed length.

Hopefully there's a patch in the pipe. I think this bit me now because my previous 5.x.x was defaulting to fixed length alpha and therefore avoiding the problem.

And just an observation...

"Bad Code", whatever that may be, is no excuse for crashing agents.

Llance,

Thanks for posting this one. Often with FOCUS it's a combination of commands that cause a crash and it takes forever to figure it out.

Carol

Llance,

Don't know if this will help or not, but when we upgraded to 7.1.3 we had to add the following line to our WF Server profile.

ENGINE DB2 SET VARCHAR OFF

Apparently IBI changed the way RDBMS varcahrs are handled.

Kevin

After almost ten months, priories have me allowed get back to this. While adding features to our self service application, I discovered a fix!!!

One place in the application we have six Dynamic Joins commands active. That is ones of the form:

JOIN JOBCODE IN EMPLOYEE TO JOBCODE IN JOBFILE AS JJOIN.

Adding A join clear after the table is done and before the –HTMLFORM BEGIN to display the report eliminate the problem. I seems to me the joins section of the agent thread is not being clear up. We are running version 5.5.3 under Windows 2003

The code is:



* * * * The Table request is Here * * * *


-RUN
-DISPLAY
-IF &RECORDS EQ 0 GOTO NODATA;
JOIN CLEAR *
-RUN
-HTMLFORM BEGIN

we, too, have a crashing problem. its only 1 fex out of 1100, and it runs fine 99% of the time, but about 1nce a day, it crashes. i look at the agent directory and the ibsnap.log..
i never figured it out, but i did add some code to help find out how far the fex was getting before it crashed. I filedef a text file to the agent, and -WRITE to it a statement after every executable paragraph..
FILEDEF MYFEX DISK fexname.TXT (APPEND
-RUN
-WRITE MYFEX parm1=&PARM1 parm2=&PARM2 ...etc
TABLE FILE CAR
...
END
-RUN
-WRITE MYFEX Got to step 1 &LINES extracted

..this helps in finding out what might be the common factors among the crashes. I would copy the entire crashed agent to a special directory, off path, and hold on to them to analyze later when i had a free moment. (whats a free moment?)
.. i did get some good advice from css, who taught me that only 1 of the .dll files mentioned in the ibsnap.log was a win2k server dll and the rest were focus dlls having to do with formatting and layout... meaning, the problem was probably something i could do something about if i worked on trying to figure it out...

This message has been edited. Last edited by: susannah,

One thing you can corrupt on an agent is the windows environment.

Try this against a long lived agent.

CMD CD \ -* Changes working directory to root

Now try until you got the same agent.

CMD DIR

And you will get the root directory

We had a sim sporadic crash in that a job was being run that changed the directory but did not set it back, since expectation is that the agent environment is completely refreshed (clean sheets as opposed to a brand new bed!)

One of the causes of agent crashing is wrongly FILEDEF'ed files.

Would suggest a search for code that includes any change directory commands as this was the prob for us...

This may or may not help, but I'll throw it out there.

We had an issue sometime last year where an agent was crashing, but it was actually the PREVIOUS procedure that was causing the problem.

A specific procedure would run and complete -- we assumed successfully. Then any other procedure that ran on that agent after that would crash. Don't ask me how we found that one -- it was a big pain.

Anyway, I can't remember for sure, but I think we finally traced it back to a very huge define (beyond the limits) that a user created in report assistant.

My point is, if you end up thinking it's one specific procedure that crashes -- or more importantly you can't trace it down to a specific procedure as it seems to vary, you might try to figure out what was running before that one.

Hope that helps. Good luck!

what Trav says sounds familiar.. there is a setting to disallow repeated use of an agent number, the numbers just increase forever until you restart the box..that way, a used agent dies nicely, vanishing completely, and the next agent just has a number 1 higher... IBI had suggested i try that, if i couldn't figure out the sort of thing Trav figured out. i can't remember the seting, but CSS can find out for you.

I think it's the agent refresh parameter on the reporting server. Default is 100 I think, meaning that an agent is re-used 100 times, then it shuts down. We have set this to a very low number (like 5) which has resulted in fewer agent abends. There is a litle higher overhead because a new agent has t start up more frequently, but we found that the trade-off was more than worth it.