Rest-API update failed

[michael85]

Dear FFAStrans comunity,

I have a issue with the REST-API Service.
I come from FFAStrans version 1.2.0 and want to update to the latest (1.3.0.2). Unfortunately I'am unable to bring the service to run.
The installed service from version 1.2.0 is working fine. Starting the latest FFAStrans brings up a message like "REST-API needs to be updated" clicking on okay leads to the error "REST-API update failed! Please restart and try again".

I have also tried to delete the service from 1.2.0 first and make a fresh install of the service from 1.3.0.2. This leads into following error:
"could not install the FFAStrans REST-API as service. Please run the manager with admin rights and try again."

OS = Windows Server 2022. I'am working with an admin User and I have also started the application as administrator. I also use UNC paths and no mounted network drives.

Any Idea how to bring the service to run?

[admin]

Hi michael85,

The FFAStrans service module is not updated from 1.2 to 1.3, so the question should not arise. Are you sure you're running the service module from 1.2 and not an earlier one?
Anyway, the solution might be simple. You can try and manually copy the file Processors\resources\ffastrans_service.exe from your FFAStrans installation location into C:\ProgramData\FFAStrans\Processors\resources. Just overwrite the existing one. But it's crucial that the 1.3 is in the same install dir that the previous 1.2.

Please try and report back.

-steinar

[michael85]

Hi steinar,
thanks for you help. The mentioned path did not exist. This is probably the reason why the installation/update of the service failed.
It seems that the zip file was incomplete due to some download interruptions or so.
Anyway, after a complete install of FFAStrans, the service runs without any problems.

Unfortunately I have another problem now.
None of my imported and new generated workflows starts to work
Manualy submiting files is working well and all workflows have a monitor node but no one catches a file.
Any Idea?

[admin]

Have you set correct credentials for the service user? If you're trying to pick up files that resides on a network share you must make sure the user has access to the folders to monitor.

-steinar

[michael85]

Hi steinar,

yes, the pickup files are stored in a network folder. I use UNC paths all over the farm. The User has also access to the network directory.
In my opinion, everything is setup correctly. And my last comment was wrong. The workflows are working but extremely delayed. The files in the watch folder were recognized really late (about 12 hours later). Even in workflows where the watch folders gets cleared after a processed clip.
Why are the workflows so much delayed?

I run FFAStrans 1.3.0.2 in a farm with 2 Servers.
I also have a older version of FFAStrans running as farm with other servers but using the same workflows. This older installation and also the servers shall be shuted down in the next days. They running in parallel until I have finished the configuration of the new servers.
The workflows on the old installation were all stopped and the FFAStrans Service on the old Server is stopped and disabled as well.
Is it possible, that this all happens because of these 2 FFAStrans instances?

EDIT: I have found another interesting detail by looking at the logs of the processed clips. from 41 Jobs were 39 of them done by Server 2. Server 1 did only 2 Jobs. It seems, that the jobs wo were assigned to server 1 stucks in the middle of nowhere.

EDIT2: I have set for one workflow only Server 2 for farming. But the ultra delayed start (I didn't wait so long) stays. I couldn't also find any files in the FFAStrans ticket folders (queue and pending).

[admin]

Why the monitors have such delay before picking up files is hard to guess without looking into the db and that might not even provide a proper ansver. Could you please zip your db folder and send it in PM? I would just like to see if there are any obvious misconfiguration or corruption.
But just to have it clear; everything was working just fine on your previous 1.2 installation?

-steinar

[michael85]

Yes, everything was working fine in version 1.2.
I have send you a PM steinar.
Thank you for your help.

[michael85]

Unfortunately I got no answer so far.
Is there a way to get a logging of what the "folder node" is doing? It would be helpful to see, if the folder node is even able to access the monitored path all the time or if the access is denied or ends in an time out.
I can not explain, why the workflows starts with such an high delay. It impacts only the new servers which were installed some weeks ago. In the meantime I had bring one of the old servers back and configured them to be part of the farm in the newest FFAStrans version. I have set up a seperate workflow where only the old server is allowed to farm (from the same storage) and this workflow is working without any delay.
The only thing that has changed, compared to old server, is that the new servers are using a 10 GBit/s Ethernet connection instead of an 1 GBit/s connection. Are some issues known by using 10 GBit/s network adapters?

[admin]

Sorry about the delay. I've looked at the logs and cannot find anything obvious and unfortunately there is no logging yet from the monitors. However, I'm adding that now and will send you a replacement file for you to test so we can see what it's doing. Hopefully it's ready by the weekend.
I don't know of any issues related to 10gig networks. I use it myself on several installations.

-steinar

[admin]

Hi, sorry for the delay. Please overwrite your existing def_runner.a3x in the ffastrans\processors folder with the one attached. Let it run for a period until you would expect ffastrans to pick up new files. Then go to the ffastrans\processors\db\cache\def_log, zip the contents and send it to me. It should reveal if files was picked up at all and when.

-steinar