Skip to main content
  • EN

Hello,

With :

 

- FME Server 2017

 

- Only 1 engine

 

- A workspace with 1 FMEServerJobSubmitter

Could you confirm that the child job launched by FMEServerJobSubmitter is always executed before any new job ?

(ie someone asks for a new job before FMEServerJobSubmitter launches the child job)

Regards.

You have two options to make sure your job runs before any already queued job:

1- Wait for Jobs to Complete must be set to "Yes"

2- If Wait for Jobs to Complete is set to "No", you have to set Job Priority to 1 and assume that you are the only one doing this on your server because if the already queued jobs have also priority 1, I expect that they will run first.

Thanks larry. Option 1 was my choice. It's logical : if the main workspace waits for child to complete, no other job can be launched, but I needed to be sure.

 

Option 2 dont work in my case, because the same workspace could be ask many times.

And with 2 engines ?

 

FMEServerJobSubmitter always uses the same engine or could use the second engine ?

Hi @mathieu_ambrosy,

I agree with larry that setting the Wait for Jobs to Complete must be to "Yes" would spin up a child process and no other job submitted could take the child process. In 2017.1.1 You would also need the Submit Jobs to be "In Sequence".

https://knowledge.safe.com/articles/55369/fme-server-troublshooting-fmeserverjobsubmitter.html

Hi @mathieu_ambrosy,

I agree with larry that setting the Wait for Jobs to Complete must be to "Yes" would spin up a child process and no other job submitted could take the child process. In 2017.1.1 You would also need the Submit Jobs to be "In Sequence".

https://knowledge.safe.com/articles/55369/fme-server-troublshooting-fmeserverjobsubmitter.html

Hi @RichardAtSafe,

 

It seems that these two pages are conflicting for "No" and "In Sequence" options:

 

https://knowledge.safe.com/articles/55369/fme-server-troublshooting-fmeserverjobsubmitter.html says that "Accepts a new job when the previous job completes" and

 

https://knowledge.safe.com/content/kbentry/55594/workflow-management-example-multiple-engines.html says that "Submits a jobs as soon as it has been received and releases features as soon as they are completed.".

 

 

 

Hi @RichardAtSafe,

 

It seems that these two pages are conflicting for "No" and "In Sequence" options:

 

https://knowledge.safe.com/articles/55369/fme-server-troublshooting-fmeserverjobsubmitter.html says that "Accepts a new job when the previous job completes" and

 

https://knowledge.safe.com/content/kbentry/55594/workflow-management-example-multiple-engines.html says that "Submits a jobs as soon as it has been received and releases features as soon as they are completed.".

 

 

 

Thanks for catching that Larry! It should be "Submits a jobs as soon as it has been received, and releases features as soon as they are submitted." I've also updated the articles.

 

Thanks larry. Option 1 was my choice. It's logical : if the main workspace waits for child to complete, no other job can be launched, but I needed to be sure.

 

Option 2 dont work in my case, because the same workspace could be ask many times.

And with 2 engines ?

 

FMEServerJobSubmitter always uses the same engine or could use the second engine ?
On your second question, the answer has more nuance. It is both possible for FMEServerJobSubmitters. A good overview can be found in this article (https://knowledge.safe.com/articles/55369/fme-server-troublshooting-fmeserverjobsubmitter.html).

 

 

But take notice that (for example) a HTTPCaller transformer always requires a second engine.

 

Thanks for catching that Larry! It should be "Submits a jobs as soon as it has been received, and releases features as soon as they are submitted." I've also updated the articles.

 

This raises an an extra question. Does that mean that when I select "No" and "In Sequence", the sequence is not respected if there is more than one engine on the server?

 

 

This raises an an extra question. Does that mean that when I select "No" and "In Sequence", the sequence is not respected if there is more than one engine on the server?

 

 

I think the wording can be confusing. The only way to start up a child process is with the "Yes" and "In Sequence". So for "No" and "In Sequence". The jobs will be submitted as soon as they enter, and released as soon as they have been submitted. The submitted jobs will find any available engines (not sub engines), and queue the rest in order. So the jobs are submitted in sequence, but are picked up by any engine so if you had 10 engines they would be 9 running at the same time.

 

 

I think the wording can be confusing. The only way to start up a child process is with the "Yes" and "In Sequence". So for "No" and "In Sequence". The jobs will be submitted as soon as they enter, and released as soon as they have been submitted. The submitted jobs will find any available engines (not sub engines), and queue the rest in order. So the jobs are submitted in sequence, but are picked up by any engine so if you had 10 engines they would be 9 running at the same time.

 

 

Then "In Sequence" means nothing at this point because all jobs are running "In Parallel". Do you think that the option "In Sequence"/"In Parallel" should be forced to "In Parallel" when we are not waiting for jobs to complete?

 

 

Then "In Sequence" means nothing at this point because all jobs are running "In Parallel". Do you think that the option "In Sequence"/"In Parallel" should be forced to "In Parallel" when we are not waiting for jobs to complete?

 

 

That's a great suggestion, and re-labeling of those terms would be a good doc enhancement, but functionally we would be loosing the order of the submissions if we moved it to "Parallel". "In Sequence" submits all jobs in sequence, its only if you are not controlling which engines / engine they are run on that they can become parallel. Thanks for your input, it helps our development.

 

 

Reply


Community Stats

30,363
Posts
115,370
Replies
38,139
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.