I have a big WF/WF Maintain install and the Reporting Server is just taking everything we can throw at it. Just working like a dream.

Except for this one little thing. Occasionally a job will remain in the "in use" state at the end of a run. It seems to be while running all sorts of different things and to be fair we're running some pretty hairy test routines on it that don't always come to a graceful conclusion.

MY QUESTION IS THIS -- Is there a setting on the reporting server that will tell an "in use" agent to quietly die after 48 hours? The nature of our work is that no one should ever have a session run more than 10 hours, so anything more than two days old would be a candidate for deletion.

I've increased the number of agents and that allows the server to run for an exceptionally long period of time without interruption (apparently weeks) but at some point I will not be on this job site and I'd like it to clean up after itself.

J.

quote:

idle_session_limit = number of seconds (-1 means unlimited)


Internal default: unlimited


This keyword is part of the general workspace features provided in the scope of an agent service. It defines the time limit that connected agents will wait for client input before they are disconnected.

Try this one. It is in the Configuration/Data Services/Default section of the reporting server console.

.


Yeah, I've hesitated because the agent's state isn't idle. But there's only one way to find out, huh?

I'll let you know.

J.


.

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

.

I don't see any change when I set that value. The server may not clean up very often so I will let this run and check again later.

J.


.

Can you tell if it is in a loop, a trace perhaps? I only mention this because you said the agent isn't really idle.

Also, you didn't mention whether this was a MAINTAIN agent or a reporting agent. If the former, is it not closing iteself properly?

.


Some of each Maintain and simple FOCUS commands. There's the remains of some really hairy focexecs but I'm not surprised by those. No loops, no execution time being used.

J.


.

John,

We have a similar situation and I am resorting to using VBScript to query the process object class to interogate the various threads of each tscom3 process.

It's still in the early stages but hopefully, when all is done, it will identify those processes that are over a certain period of "execution" time and will not only kill the process but tidy up the EDATEMP folder afterwards.

At the moment I am short of matching threads to resources but with time I am hopeful

T

Hi John,

Our iWay people reviewed this one and suggest that this one should be addressed by a case with Information Builders' Customer Support Services, as we will need to gather your traces and logs for review. You may either call at 1-800-736-6130, or access online at InfoResponse.

Cheers,

Kerry