Double render jobs on Backburner

[Nick Jensen]

Hey guys,
We have a small issue with single frame jobs starting on multiple servers. Only occurs when submitting through RPMan. And it is not consistent. I can't for the life of me figure out what is causing it. Only solution is to limit backburner to one server pr. job - which is a bit counter productive when we're also submitting animations occasionally.

- any ideas? Is it some stupid checkbox hidden in a submenu somwehere?

Cheers,
/Nick

[Nick Jensen]

*Bermp*

[admin]

I'm not sure either.

Do you find it does it through both command line BB mode and non-command line BB mode? (Enabling any of the 'extra submission options' will enable command line BB mode, the submission feedback indicates when it is command line mode).

If I had to guess I would say that when the job is submitted backburner creates the job and slaves can see it *before* it sets any machine limits, so by the time it does set it, multiple slaves have picked it up and it's too late.

As a test, if you submit suspended and then manually unsuspend, do multiple slaves ever pick it up? Or does the suspension get in too late too I wonder (though jobs should just be dropped).

If submitting suspended and unsuspending didn't ever have multiple slaves pick it up then I could set it up so that RPM always submits suspended, then after a suitable delay (maybe a second would be enough) it could auto connect to the manager and unsuspend them. Would add a small amount of time to the submission is all - but that is assuming that actually does work.

Another clue would be if multiple slaves only ever pick up jobs when there are multiple idle slaves at the time of submission.

cheers,
grant

[admin]

I'll add an option to 'Submit Suspended Then Auto Resume' - resuming the submitted job will require RPM taking control of manager, which means that if anyone has Monitor open it ask them to give up control (with a 10s timeout that auto approves) so it's not terribly ideal but will make testing this easier.

cheers,
grant

[admin]

Hi

Try the option at the bottom of the Extra options in the BB rollout, 'Submit suspended the auto resume'. If the main "Suspend" option is on, this will not auto resume (it should really grey out if that is on). It'll try to get control of the queue after submitting, which may mean an existing open Monitor will have to give it up.

http://www.rpmanager.com/installers/RPM ... p_6.67.exe

Let me know if this behaves any differently for this issue.

cheers,
grant

[JClarke]

I haven't used your new version of RPM yet, but I can confirm your theory of submitting as suspended solving the issue. That's plagued us for years and I could never figure it out, we had even been starting to get occasional corrupted frames on our network recently because somehow multiple machines were saving over the same file simultaneously due to this backburner issue. Thank you!!

[Nick Jensen]

Thanks Grant - I'll take it for a spin, and get back to you soon.

Cheers.,
/Nick

[Nick Jensen]

aaaand back.
Sorry, but the updated version doesn't change anything. It still submits to at least two servers simultaneously.
- but big thanks to JClarke - your suspended-solution does the trick, and will have to do so for now.

Grant: thanks for trying. If you need any additional info, or wan't me to test something else, let me know.

Cheers,
/Nick

[admin]

Can you see it submitting suspended and then unsuspending?

The manual unsuspend step must be required for some reason, though I wonder if a longer delay would help... glad the suggestion to try submitting suspended and unsuspend is workable.

grant

[Nick Jensen]

Hey Grant,

I can't see it suspending/unsuspending - maybe the delay is too short? Perhaps, as you say, a bit longer. Maybe a couple of minutes?

There's also 15 of us potentially being the current queue manager - does the submitee have to gain control of the queue in order for the unsuspension to work?

Cheers,
/Nick