It looks like WF restarts a fex if it takes longer than 1 hour? How do I turn that off, so that it can finish?

I'm not amused having an hour of my time wasted.

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

I would suggest putting in a case with IBI, you will probably need to turn on traces as well to see what is going on.

I opened a case, but my expectations aren't high; IBI's tech support is pretty abominable in our experience.

quote:

IBI's tech support is pretty abominable

- I don't really think so - you have to know how to work with them. Provide screenshots and other evidence, provide a reproducible example...

Meanwhile, how do you know that a WebFOCUS request "restarts" after one hour? Have you noticed this from the WF Server Console? Is this running in WF ReportCaster? A little more detail would be helpful.

quote:

I'm not amused having an hour of my time wasted.

What is one hour on a livetime.....(less then 0.0002% if you are lucky)

I already had the impression this was happening sometimes, but never could prove it before. This time I was watching while the fex got restarted though.

Recently we've been adding some logging to our fexes (mostly for debugging/performance tuning while they're in development) and I witnessed the log lines that are at the start of the fex repeat themselves after the fex had been running for an hour (at the second!).

Checking the timestamps of the created hold files confirmed this beyond any doubt.

I'm the only user on this machine, reportcaster isn't running and I certainly didn't restart the fex myself. Hence it has to be something automatic, quite possibly some watchdog assuming the agent crashed after an hour.

---

Regarding tech support; It usually takes a _lot_ of effort from our side to get one of IBI's people to finally reproduce the problem, which takes lots of answering of questions they could easily answer themselves if they'd just run our provided test-cases. Our issues can rarely be captured in screenshots, yet we still get asked for those sometimes, even though it's impossible - that doesn't really come across as convincing support.
Then when they reproduced it and take it upstream (often a month or more of asking hence and forth later) it happens that they get told that that particular bug is a feature they're not going to fix!

We've seen a few bugs fixed for us in hotfixes, but it takes so much of our time that we rarely bother reporting them anymore.

No, we're definitely not happy with IBI's tech support.
Perhaps I'm spoiled by the support many open source communities provide (PostgreSQL's support is a particularly good example). I'm used to having a fix within 24 hours, if I even encounter a bug.
Then I think I encountered exactly one issue in over 10 years of using Postgres, while my case file on IBI contains at least a dozen issues already and I haven't been using it for a year yet.

How are you running this program? Through the WebFOCUS Server Console? Since this does not run in ReportCaster, a program that takes over an hour to run is not very web oriented, or is it a fex that prepares data for other report programs?

I've never heard or experienced what you're describing, a fex restarting exactly one hour after it started. Have you tried restricting the data it processes so that it takes 45 minutes? Does it complete if it takes less than one hour?

Oh, and since it restarts exactly one hour after it started, does it ever end?

It is indeed a preprocessing fex. It processes a bunch of data into aggregated results that we (plan to) use in other reports. That it does take an hour is actually a bit strange, as it's taking the longest time converting an ftm file (created by MATCH FILE) in the same order into a focus file with an index.
For some reason that step takes almost 40 minutes, while creating the ftm file only took 8 minutes... There's no sorting going on (just a PRINT with no BY fields), so it should be a straight conversion, with some fields to index as extra work.

That step does finish though, it's the step after it (in which a relatively small focus database is joined to it), that hits the 60 minute limit of the fex about 10 minutes in.

I think it's possible that the process runs low on memory during this, which could be the cause of some kind of watchdog kicking in. Could it be something outside of WF even?
I don't think Windows (XP) has something like the Linux OOM killer, but if it does, that is a probable suspect. How that ends up with the agent restarting the fex, I have no idea.

Strangely enough, in the end - even though I had to kill the restarted agent to prevent it from overwriting the data - I seem to have a usable focus database. I expect that it may be incomplete/corrupted though?

Sounds like you have a connection limit on your data service configuration.

Is this a dev studio request or a deferred request?

There could be a connection limit on the data service, maybe connection_limit, but I have never heard of a job restarting after being killed by this setting.

I have never had this setting other than -1 and in practice have had test jobs running for 22 hours building test data, and this was 850GB. If you do not end up with a 30GB data file, there is something decidedly wrong.

Advice is always to build large data files without the index, to do this automatically with FORMAT FOCUS, you can try:

APP HOLD BASEAPP
TABLE FILE fn
PRINT *
ON TABLE HOLD AS HOLD1 FORMAT FOCUS 
END
-RUN
SET XRETRIEVAL=OFF
TABLE FILE fn
PRINT *
ON TABLE HOLD FORMAT FOCUS INDEX PROJECT
END
-RUN
APP COPYF BASEAPP HOLD MASTER BASEAPP HOLD1 MASTER
-RUN
REBUILD
INDEX
HOLD1
* 

which should allow you to build 7 indices on the file.

We had a similar case a few weeks ago. The customer had an optioned turned on in their WebSphere server HTTP where it assumed that any request it passed on which took more then 5 minutes must have been "lost" and the feature decides to re-issue the request. Sounds like your threashold is set to 60 minutes.
Turn that feature off!

We use Weblogic and what Brian mentions does occur, but it doesn't kill the original agent it just spawns new agents. There's a recent thread that I opened about it below if you search on "Agent Spawn"

You're probably right about this being caused by something else in our environment(s). The question remains where to look.

We use a combination of IIS - ISAPI - Apache Tomcat. Either end of that chain could be causing this, but I suspect we need to change a setting in Tomcat's config somewhere.
Unfortunately, Tomcat's configuration is a maze. Perhaps if I were just looking for a needle in there - that would be easy in comparison! I know what a needle looks like.
Any hints about what setting in which file I'm looking for?

This does raise another question for these forums though, I'll put that in a separate post.

I would look at IIS settings. Turn your tomcat logs on and you should see another request coming in after an hour.