If you run the master process on the 32-bit engine the sub processes can't run there because it's already busy. If it's possible to run the master one on a 64-bit engine you should be able to use job queues to restrict the child processes to the 32-bit engine. You can specify the job queue in the FMEServerJobSubmitter as well as in the FME Server interface (you will need to assign the job queue to a repository and an engine)

Is this behaviour specific to running the master process on 32-bit? I know when running on 64-bit as "In Sequence", it runs using the same engine. It sounds like this would tie up both a 64 and 32-bit engine. The process takes about 5 hours to run, so it will mean we might need to purchase another engine. It is good to know this may be an option, though.

No, but by setting the master workspace to wait until jobs are completed it will tie up that engine until all it's subjobs are done and if that engine is your 32-bit one the subjobs will not be able to run on that.

So either you use job queues to make sure the right job runs on the right engine or you try and use an automation for the subjobs but depending on your pre- and post-processing (which would have to be done in separate workspaces then) it might be too much of a hassle to set it up.

Whether or not you need an extra engine is something you need to decide, 5 hours is a long runtime though but it really depends on how often it needs to run.

Hi @jnfung,

I have been able to reproduce this issue and it appears that when the child processes launch they use the template engine definition in the configuration logs to launch child processes. By default this is set to the location you installed FME Server. When adding the 32-bit engine you had to modify this configuration file so that Engine was pointing to another location. I have reported this issue and will update this post if it is fixed.

As a workaround I would suggest:

a) Installing the 32-bit engine on a separate machine. This way it has its own set of configuration files so when the child engine uses the template definition this is correct.

Or

b) Set Wait for jobs to Complete=No and use job queues to ensure that all the child jobs only run on the 32-bit engine.

@redgeographics - this is not quite correct. If you use FMEServerJobSubmitters with Submit Jobs=In Sequence and Wait for jobs to Complete=Yes then this will launch child FMEEngine.exe processes from the parent Engine. This means that as you have said the parent workspace ties up the main Engine until the child jobs are complete but these jobs do not run on the other engines. You will see on the Engines and Licensing Page additional engines appear e.g. EngineX@123 where EngineX is the engine running the parent job and @123 is the ID of the Parent Job. Since the sub-processes are launched from that specific engine we would expect them to generate the same engine type.

The way engines are used for the different parameter settings is explained in more detail here.

@hollyatsafe Do you have information when it will be fixed?

Hi @witos,

This issue has been marked Closed: Won't Do, which means that currently we do not have enough requests to target this issue for development in the short-term. However I have made a note that you are also encountering this issue, as these can be reassessed if more information comes forward.

What we ended up doing in the end was submit the FME Server requests for the different sub-processes from the source application. When our source application receives a response back from FME that one child process is done, this triggers the next one to be submitted to FME Server.

I think depending on the situation and nature of the jobs being run different workarounds for this should be used. Some require more or less effort to implement, and others have implications on engines or hardware required. Overall, @hollyatsafe provided the most useful suggestions.