Ive been noticing a few tasks have been attempted multiple time (multiple logs for the task) but not erroring.
The last line in the log is this:
0: In the process of canceling current task: ignoring exception thrown by PluginLoader
What does that usually mean?
We have been getting it a lot with fumeFX simulations and some Vray renders.
Hi Jordan,
It’s impossible to double guess the reason for a task cancelling unless the entire log report can be seen so it can be placed in context of what the plugin was doing at that exact moment of failure.
Mike
Usually that simply means the task was requeued. Check the requeue reports for that task to see how/why it was requeued.
There is no requeue entries in the task history… the logs are very unhelpful, they is just stops: (ive trimmed the start, its just the normal start up stuff)
[code]0: INFO: Ignoring popup “FumeFX: Frame -8 (-20 - 72)”
0: INFO: Ignoring popup “FumeFX: Frame -7 (-20 - 72)”
0: In the process of canceling current task: ignoring exception thrown by PluginLoader
Log Details
Log Date/Time = Aug 15/11 17:41:47
Frames = 0-0
Slave Machine = Chain41
Slave Version = v4.0.0.40330 R
Plugin Name = 3dsmax[/code]
Just to confirm, are you looking for the requeue reports in the task’s right-click menu? They should be under Task Reports → View Requeue Reports. If the task is getting requeued from the Monitor, or cancelled from the Slave UI, a requeue report should be generated…
The task only has log reports in the right click menu.
Something interesting we did see was this from the slave log window, but nowhere in monitor:
Scheduler Thread - Cancelling task because task filename "\\bachlibrary\deadline_repository\4\jobs\004_070_011_60c123fe\Rendering\004_070_011_60c123fe_00000_0-0.Chain29" could not be found, it was likely requeuedIts all very odd. Certain files will simulate for 20min then requeue 4-10 times then eventually once it gets past the 20min mark it will sim fine for 6 hours.
That sounds like this problem:
viewtopic.php?f=11&t=6040#p24198
The details are discussed there, so all we need you to do is enable slave verbose logging so that the slave will dump the contents of the task folder to its log when this happens. Post the log and we’ll take a look.
Cheers,
Ok… sorry this took so long… wouldnt you know it, as soon as you want one to fail it wont 
2011-08-23 23:12:23: 0: INFO: Ignoring popup "FumeFX: Frame 46 (0 - 104)"
2011-08-23 23:12:51: 0: INFO: Ignoring popup "FumeFX: Frame 47 (0 - 104)"
2011-08-23 23:13:19: 0: INFO: Ignoring popup "FumeFX: Frame 48 (0 - 104)"
2011-08-23 23:13:48: 0: INFO: Ignoring popup "FumeFX: Frame 49 (0 - 104)"
2011-08-23 23:13:59: Scheduler Thread - Cancelling task because task filename "\\bachlibrary\deadline_repository\4\jobs\004_070_011_74831975\Rendering\004_070_011_74831975_00000_0-0.Chain15" could not be found, it was likely requeued
2011-08-23 23:13:59: Scheduler Thread - Contents of job's Rendering folder:
2011-08-23 23:13:59: sending cancel task command to plugin
2011-08-23 23:14:01: 0: In the process of canceling current task: ignoring exception thrown by PluginLoader
2011-08-23 23:14:01: 0: Unloading plugin: 3dsmax
2011-08-23 23:14:16: Scheduler Thread - In the process of canceling current tasks: ignoring exception thrown by render thread 0
Thanks for the log! This line confirms our suspicions:
As you can see, no file names are printed out after this line, which means the slave can’t see any tasks for this job. Some kind of network hiccup must be causing this…
Perhaps what we can do to avoid this going forward is to count the number of task files that the slave can actually see, and compare that to the number of tasks the job is supposed to have. If they aren’t equal, the slave can assume there was some network issue and keep rendering the job.
Cheers,
So for each task there should be a file in one of the folders denoting what state the task is in? If so then that would seem ideal!
Yes, that’s correct. In version 5, they were actually all moved to the same “tasks” folder, which will actually make doing this check easier since we only have to check the contents of one folder.
We are targeting this improvement for Deadline 5.1 (which is currently in beta).
Cheers,
I actually think this is going to help overall task stability lots when a repository is under heavy load when a studio decides to submit their large data files with their jobs. I’m excited to see this new functionality in action!
M