I wouldn’t normally recommend this, but your strange Max renders have no pattern. Sometimes they fail, sometimes exactly the same files as you said that were failing, now start working on the same machines that were previously failing.
Deadline v6.0 ships with Mongo v2.4.1, so using v6.0 or the beta version which provide at least this version.
I suggest if you can; to install mongo + repository to a “new” location and then you can just switch a couple machines to the “other” repository so it can be tested and verified as resolving your issues. You then also have a backup plan to revert if necessary. There are also a few bug fixes/tweaks to the Max plugin in the beta release, which might assist here as well.
installing them to a new locaton was the plan anyway, so i will leave the old repository as it is for now.
Now how about the old MongoDB any advice on that?
i have to say that some of this could be network corruption? a bad cable, switch?
i say that because SUBMITTING from SMTD results in a copy of the max file being put on the repository [normally] - but i dont recall this being how backburner works.
just pointing out a potential in-your-face difference. if the copy is the problem, then i would look at the network path and equipment for that copy of the max file. perhaps under load a network cable or port is causing corruption.
cb
Ok, it might be a little early to be sure but i think we have a stable running Deadline now. Here is what happend so far.
First i uninstalled the MongoDB and the Repository and reinstall it on another drive on the same server but this time using only your Repository Installer.
During the installation there was a problem, there was a “Waiting for MongoDB Service to Start Listening” dialog box that kept running and constantly failing to… listen i guess 
.
I found this thread from Mike Truly having the same Problem. He simply aborted the “Listening” part and tested if the Database is running using cmd, so did i and it looked like the service is running properly.
So next i installed the Repository and connected to the database. The Monitors and Slaves were responding and Everthing looked fine.
To test the new installatioin i sent one of the jobs that caused so many problems the last time and the result was pretty much the same, lots of errors and corrupted files.
The next thing i did was to install the Repository and the Database on a completely different machine, i chose one of the older and not much used render nodes with Windows 7 OS. The installation was better allready,
no errors whatsoever, it just installed the MongoDB and the Repository without any issues. I switched all the slaves to the new repository and sent the bad jobs to Dealine once again.
Running for 4 Hours now with 0 Errors
Ok, i guess time to Troubleshoot now, of course first we have to look what’s wrong the previous server maybe Ryan is rigth and there is some bad cable or a damaged network card or switch.
But to exclude some any software related issues some questions in advance to you guys:
- Have you allready successfully installed and tested MongoDB and Deadline on a Windows 2012 Server OS?
- Have you allready successfully installed and tested MongoDB and Deadline on a Virtual Server or do you know about other people with the same configuration who don’t have the same issues we have?
Thanks!
We have tested MongoDB and the Repository hosted on both Linux and Windows VMs, and they have worked as expected. For the Windows VM tests we used Server 2008 R2.
Thanks Coulter,
than i guess the VM shouldn’t be a problem. So how about the MongoDB version, I went to MogoDB.org and saw that “Windows Server 2012” OS requires a 2008R2+ build of Mongo, is this
the Build included in the Repository installer?
No, this isn’t the build that is currently shipped with Deadline. It looks like we’re currently shipping with the 64-bit legacy version. Maybe that’s something we can look at changing in the future.
Cheers,
- Ryan
That would be great! Do you see a chance it could be shipped with the final release of 6.1? 