Hi guys, I am experiencing strange behavior with Deadline 3.1. I am cleaning up the repository, doing so I found out that the job reports are not always deleted.
I have only 3 jobs left in the repository yet I still have hundreds of job report folder in the /report/jobs folder.
We weren’t aware of this issue, so no, it wouldn’t be fixed in 3.1 SP1. Now that it’s on our radar, we’ll log it as a bug. It should be easy to add some code to purge log folders when they’re corresponding jobs no longer exist.
I finished the upgrade and I still get these corrupted job email reports.
The job with ID 00a_100_999_75f2ac58 appears to be corrupted. This usually means that either the job XML file has become corrupt or it is missing. You should check this job in the repository to see if it needs to be deleted manually. This message is being sent from R134
The original corruption message was:
Could not find file ‘\deadlinesrv\DeadlineRepository_v3\jobs\00a_100_999_75f2ac58\00a_100_999_75f2ac58.job’. (Job has been corrupted, it is recommended that this job be removed from the repository: 00a_100_999_75f2ac58) (Deadline.Jobs.JobCorruptedException)
When I look in the repository, the job doesn’t exists… i don’t understand why this is happening… where is this job… why are the slave trying to find this job that doesn’t exists?
i get the message from slaves… i only got one since the upgrade. come to think of it I had one or two slave still rendering during the upgrade. I sent a restart slave after current task command… That might be why I got the message.
I’ll wait a bit more to see if I still get corrupted job reports like I had before the upgrade.
Slave X store the repository in cache, pick up a task, then start rendering that task…while the render is in progress a job gets deleted.
When the slave finish rendering it checks the job using his cache, but the job that got deleted (that exists in the slave cache) doesn’t exists in the repository anymore, so the slave sends a corrupted job email.
I was under the impression that the job reports were controlled by the “Days to Keep Monitor Logs” option and independent of the job being deleted. I haven’t tested that theory.
Yes, i think you might be right… but does it make sense to keep the log after the job was deleted? I think it might be useful, but how can I access the log through the monitor after a job was deleted… is it even possible?
This is actually for the local logs on each machine, which are created for each application. This is separate from the job logs. As I mentioned earlier, we will probably just add a job log purging feature to clean up reports for deleted jobs.
We’ll have to do some testing to see if we can reproduce these results. In the meantime, if you happen to stumble across the steps to reproduce, please let us know!