AWS Thinkbox Discussion Forums

[API] Create report when RepositoryUtils.SetJobFrameRange is called?

We have certain job types that are submitted with a single task, which then generates a new set of tasks and uses RepositoryUtils.SetJobFrameRange to change its own frame range in place, triggering an automatic re-queue of task 0. This works fine, except that no job report is ever created for that first run of task 0, so debugging it is a pain.

Is there a way to force a report with the log of the first iteration of the task to be created in these situations, like it is when a task is re-queued from the monitor?

The first task generates a new job? This may be causing more trouble than I’m not expecting, but why not just create that other job with an event script? That would get logged in the job reports as normal.

I think the problem is that the task is killing itself. Requeuing a running task should throw away the current job report normally.

No. The first task runs some code that generates new work to do, and then changes the frame range of its own job based on the amount of work that was generated, which triggers a re-queue. In other words, it’s a one-time operation, and fundamentally changes the underlying job (ours, not Deadline’s).

When a user re-queues a running task, it creates a “Requeue” report for the job that includes the task log up to the point it gets interrupted. I would like to do the same thing programmatically.

Shouldn’t be too hard to add, considering we already do it when requeueing from the Monitor. This is really more of an oversight on our part than anything else, we’ll have a look at it :slight_smile:

Cheers,
Jon

I just wanted to check and see if there were any plans for adding/fixing this (depending on your perspective :wink:).

Looks like we added it back in 8.0 SP10. You should be good if you upgrade.

Hmm… We’re using 8.0.12.4, but no reports are being generated for these frame range changes.

After digging through the code, it should definitely be created when calling this guy: (that you are using based on the original post(

RepositoryUtils.SetJobFrameRange( Job job, string frameList, int chunkSize )

We created a function to add requeue reports on top of the older one… Hmm. Let me play around with this a bit today, there may be something up with this.

Update:

It looks like I only get a requeue report when the job is rendering. I’m thinking we should probably make this happen anytime we call the queue and we should probably adjust where it claims the queue happened, because this wasn’t from the Monitor:

=======================================================
Reason
=======================================================
Queued task was manually requeued from Monitor.

User: edwin.amsler
Machine: Mobile-029.local

=======================================================
Log
=======================================================
No slave log

=======================================================
Details
=======================================================
Date: 2017/05/12 09:23:12
Frames: 3
Elapsed Time: 00:00:00:00
Slave Name: (no slave)

Here’s the test shim:

Mobile-029:tmp edwin.amsler$ cat test.py 
from Deadline.Scripting import *
from FranticX.Diagnostics import *

job = RepositoryUtils.GetJob("5915c3c1e9faf11eba38a048", True)
RepositoryUtils.SetJobFrameRange( job, "1,2,3", 1)

I’m not sure what else I can say… I’m definitely not getting these reports, in spite of the fact that SetJobFrameRange is being called while the job is rendering.

Here’s the whole picture:

  1. The job is initially submitted with a single frame (1).
  2. That one frame does some checks and then may or may not discover that it needs to run many tasks instead of just one.
  3. If it does, it triggers a web service script that will set its own job’s frame range to 1-N (where N is the number of tasks it needs), and then goes to sleep until its task is requeued.

My workflow was the following:

  1. Submit a command line job with some 5,000 tasks
  2. Let a few tasks complete while it’s rendering
  3. Call the script I posted before
  4. Check tasks report

To be fair, I got it on the first try, so I didn’t run the script multiple times. I’ll keep this tab open and circle back later in the day after more testing. It might just succeed randomly?

Privacy | Site terms | Cookie preferences