Solved

Job termination due to version difference on micro level

  • 9 October 2019
  • 4 replies
  • 3 views

Badge +2

Hi, We have a workspace that runs fine on our FME Server testing environment yet crashes on our user acceptance environment. It crashes on version incompatibility, like described in the article at https://knowledge.safe.com/articles/363/workspace-fails-on-fme-server-fme-version-incompat.html

Granted, we use FME Server build 17650/win64/2017.1.1.0 and FME Desktop build 17652/win64/2017.1.1.1. that would be a cause for not running a workspace due to compatibility issues.

However, this baffles me: FME Server version is the same, workspace is the same, what else could cause this behaviour? 

I narrowed it down to the workspace below, which is basically a SpatialRelator comparing two box-like area's. Our testing environment runs it just fine, and concludes in the log:

2019-10-09 12:23:30|   0.3|  0.0|INFORM|Loaded module 'SpatialRelationshipFactory' from file 'D:\Prog\FME\FMEServer\Server\fme\plugins/SpatialRelationshipFactory.dll'
2019-10-09 12:23:30|   0.3|  0.0|INFORM|FME API version of module 'SpatialRelationshipFactory' matches current internal version (3.8 20170315)
2019-10-09 12:23:30|   0.3|  0.0|INFORM|Emptying factory pipeline

Our user acceptance environment is however very strict, and for the same workspace it concludes:

2019-10-09 12:00:37|   0.1|  0.0|WARN  |Library 'D:\Prog\FME\FMEServer\Server\fme\plugins/SpatialRelationshipFactory.dll' was found but could not be loaded. Ensure that all the dependent modules exist for this library
2019-10-09 12:00:37|   0.1|  0.0|ERROR |This FME edition does not recognize the `SpatialRelationshipFactory' factory. Please ensure that the current platform supports this factory, the factory name is spelled correctly, and that you have installed all required plug-ins

and terminates the job. 

Workspace: 

Yeah, true, it's not an AreaOnAreaOverlayer but it is a SpatialRelator, however, using an AreaOnAreaOverlayer does not produce a crash. 

Any ideas?

icon

Best answer by mark2atsafe 9 October 2019, 17:06

View original

4 replies

Badge +2

Oh, forgot to tell, SpatialRelationshipFactory.dll have the same date/version/size etc on both servers.

Userlevel 2
Badge +12

Nothing about SpatialRelator in the change logs for these versions (2017.1.1.*).

I would send a question to www.safe.com/support

Userlevel 4
Badge +25

I searched in our systems and I don't see this DLL fail to load before except in the case where it had been quarantined by a virus scanner. Could that be the case here?! Another reason could be the FME license type. Is it possible that the two systems are using different licenses?

I can't imagine it's a conflict with a DLL from another product with the same name (as has sometimes happened). Do you have multiple FME versions installed on that system?

You could try using a tool like Dependency Walker which might highlight what the issue is, although I tried it on my functioning version and still got warnings, so I don't know how useful it will be.

If nothing here helps, then I would file this as a support case and ask our team to check with the developers.

Userlevel 4
Badge +25

I searched in our systems and I don't see this DLL fail to load before except in the case where it had been quarantined by a virus scanner. Could that be the case here?! Another reason could be the FME license type. Is it possible that the two systems are using different licenses?

I can't imagine it's a conflict with a DLL from another product with the same name (as has sometimes happened). Do you have multiple FME versions installed on that system?

You could try using a tool like Dependency Walker which might highlight what the issue is, although I tried it on my functioning version and still got warnings, so I don't know how useful it will be.

If nothing here helps, then I would file this as a support case and ask our team to check with the developers.

Also check the properties of spatialrelationshipfactory.dll to see what the permissions and security settings are.

Reply