Hosts take same job

[Borky]

Hi there,
we are currently running a small farm that solely encodes to mxf op-atom and every now and then, two hosts will start a job on the same file. Is this a common issue and is there a quick fix for that?

Thanks in advance.

[admin]

Hi Borgy,

This should not happen. Ok there is no 100% fool proof way of making sure it absolutely never t happen but it should be so rare that it's worth investigating. First, I need you to export the logs for one of the duplicate jobs...that is both of them... and post them or send them to me as DM.
Thanks.

-steinar

[emcodem]

Ok there is no 100% fool proof way of making sure it absolutely never t happe

DB cuffcuff

[admin]

My god, @emcodem, did you catch a cold?

[emcodem]

Yeah, doctor sayin i got Vitamin DB deficiency

[FranceBB]

Yeah, doctor sayin i got Vitamin DB deficiency

lol
Jokes aside, in 9 years and 4 months of FFAStrans usage I've never really run into an actual effective concurrency issue.
Lots of things changed over the years, but the file based database with the various tickets (json) has been able to cope quite perfectly.
Especially with FFAStrans 1.4.1 and future releases that ship the database optimization, hosting the DB is not even so demanding in terms of resources and the overall system and the various hosts feel snappy again. I don't even have the missing workflows any longer nor I find any workflow in the corrupt subfolder any longer unless something catastrophic happened.
With the latest releases, I feel like we're pretty much at a very good point in terms of stability.
Nowadays, the concurrency and access racing issues seem to be caused mostly by eventual misconfigurations or errors on the end user side rather than something the system is actually doing.

Honestly, the DB has never been more stable and even with FFAStrans 1.4.2.10 which I'm currently testing I haven't really seen any issues on that side.
Kudos as always to Grandmaster for everything he has done on this side and for implementing quite literally everything we asked for in terms of checks to prevent having corrupted workflows or other issues. Even the situation with stuck json files in the monitor folder got much much much better with the latest version. Honestly, I don't really have any complains or indeed reasons to ask for anything different like a DB. Besides, running with a file-based database means that FFAStrans can run in a portable fashion everywhere which is actually quite something in this day and age.