This project has moved. For the latest updates, please go here.

Unexpected behavior with ExecutionTimeLimit set

Feb 23, 2012 at 2:29 PM

Hi to all,

  I tried to retrieve the last status of a job after it was terminated by scheduler because of exceeded time limit on W2K3 Server.
I noticed that in this condition scheduler doesn't set the status as "terminated", but it leaves the last status before the last timed-out execution.

I don't know if this is the expected behavior or if it's a bug, but after a job is timed out the last status is not referred to last run but to the run before!

Anyone can confirm this "issue" also on other SO?

F.

 

Coordinator
Feb 23, 2012 at 9:58 PM

The Task.TaskState property will only provide the following states. Given that V1 (pre Vista) of the library returned a richer set of states, those are grouped into this simpler set. Check the code for Task.cs and find the Task.TaskState property to see how that is done.

/// <summary>The state of the task is unknown.</summary>
Unknown,
/// <summary>The task is registered but is disabled and no instances of the task are queued or running. The task cannot be run until it is enabled.</summary>
Disabled,
/// <summary>Instances of the task are queued.</summary>
Queued,
/// <summary>The task is ready to be executed, but no instances are queued or running.</summary>
Ready,
/// <summary>One or more instances of the task is running.</summary>
Running

You may get some further information by looking at the Task.LastTaskResult value.

Feb 24, 2012 at 1:29 PM

I think isn't a bug in your code.

I suppose that when MS Scheduler terminate the job because of a time limit, it update the last time but not the status.
I looked for a workaround using pid engine to retrieve exit status but I wasn't able to find the task pid...

could you suggest anything?

Thanks,
F.