Skip to main content
  • EN

I have been running my workspace (which unfortunately I cannot easily share) that uses a number of PythonCallers which each writes to the log file via the FMEObjects calls. What I have found is that when running the workspace from the GUI all the log messages are written to the log file. But when running the workspace from the command line I have found that some installations of FME will log all the details while others will not. Is there some configuration file or command line option that would force FME to record all log messages to the log file?

Can you give more details about the installations that are logging correctly versus the ones that are not?

 

 

All installations should be Build 16674, which should have been installed as standard from the installer. Are there any more specific details you would like to know about the machines in question?
All installations should be Build 16674, which should have been installed as standard from the installer. Are there any more specific details you would like to know about the machines in question?
No, I was just wondering if there was different version of FME used.

 

You can configure it in workbench:

You can configure it in workbench:

I think this is a great suggestion to verify here!

 

 

>What I have found is that when running the workspace from the GUI all the log messages are written to the log file.

 

Do all installations correctly log out, when the workspace is run from the FME Workbench GUI?

 

 

You can configure it in workbench:

I have asked regarding this and it appears that they have the exact same configuration set. Also they have tried all possible python interpreter options with no improvement.
>What I have found is that when running the workspace from the GUI all the log messages are written to the log file.

 

Do all installations correctly log out, when the workspace is run from the FME Workbench GUI?

 

 

With the test data I've been working with the FME workbench does fail due to exceptions being generated in the PythonCallers from bad input data. The debug messages provide the required context for the failure so we need it to output to the log even if "Warning: not all FMESessions that were created were destroyed before shutdown. This may cause instability" is reported.

 

I have had the client confirm that the Build numbers are the same.

 

They report that the command line console shows the required log information coming from the PythonCaller but these same details don't get written to the log file specified.
I have had the client confirm that the Build numbers are the same.

 

They report that the command line console shows the required log information coming from the PythonCaller but these same details don't get written to the log file specified.
Hmm, I may have misunderstood your initial report. The logging is coming from PythonCaller transformers. Is that correct?

 

For FME Server Engines, Python is not typically logged to the Job Log file, rather it is recorded to the fmeprocessmonitorengine.log file. (See this Q&A; Post) That wouldn't explain why some do and some don't.. Please check that log file on FME Server and see if that is where the missing messages are found!

 

 

Hmm, I may have misunderstood your initial report. The logging is coming from PythonCaller transformers. Is that correct?

 

For FME Server Engines, Python is not typically logged to the Job Log file, rather it is recorded to the fmeprocessmonitorengine.log file. (See this Q&A; Post) That wouldn't explain why some do and some don't.. Please check that log file on FME Server and see if that is where the missing messages are found!

 

 

After the client returned and checked processes related to the FME deployment and execution it was found that they had an issue with their SVN update and had not been correctly updating all FMW files.

 

Indeed the logging was coming from a PythonCaller but with the default logging status of Inform. Therefore, I'm going to accept the answer given because of the possible configuration differences that could have caused the issue.

Reply


Community Stats

30,185
Posts
114,571
Replies
37,848
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.