FME server doesn't create log for failed workbench

How are you triggering the job? I’ve had similar issues when a scheduled job runs, but couldn’t view the logs. Manually running it through Flow then alerted me to a custom transformer missing

You need to look at the “Result Data” on the Log page, as it will likely explain that the process has not started for a reason (and thus why the log hasn’t even started to be created)

Hi

I don’t think anything is missing, this job normally runs to completion but when it doesn’t there is no log. The job is triggered through an automation, when i submit it manually it works - but then that is the norm anyway.

This is running in server, there is no “result Data”, indeed no log at all!

Result data is part of the log page in FME Flow, rather than part of the log file. For instance:

todd_davis wrote:

Result data is part of the log page in FME Flow, rather than part of the log file. For instance:

 

Thanks for that, it doesn’t give much away…. 

And the log file doesn’t exist on disk

Now raised with Safe support. Engine is failing at the same time but not for every job submission

I’m seeing the same behavior.  I have an automation that runs every 5 minutes and sometimes it fails but there’s no log file created. 

jonvelco wrote:

I’m seeing the same behavior.  I have an automation that runs every 5 minutes and sometimes it fails but there’s no log file created. 

 

When we looked in the server logs there was a corresponding engine failure and I was offered a potential fix by SAFE….

“By setting these parameters to 1 the jobs will restart after every run. This can lead to a clean engine and prevent any issues with previously loaded dll's and Python interpreters.  The restart of the engines should take less than a second. Even if this isn't a long term solution it would be great if we can test this to refine the issue.
In: C:\Program Files\FMEFlow\Server\fmeServerConfig.txt
 
MAX_TRANSACTION_RESULT_SUCCESSES=1
MAX_TRANSACTION_RESULT_FAILURES=1”

We have a very busy server and obviously there is an overhead in this as the engine restart takes resources. However I did try it and setting the parameters to 1 seemed to fix the problem  but according to the logs this added about .5s to the task. Reverting the parameter values caused the failures to reappear.

Ultimately the failing job was doing a huge amount of work at startup with many readers and filtering in the workbench. I replaced them with SQL Creators with quite complex but efficient SQL to pre-filter the rows and reduce the read overhead considerably. Not only did the issue disappear but also the workbench ran considerably faster.

Hope this helps

Rob