Geoprocessing Packages broken when upgrading to LocalServer 100.9

880
3
02-01-2021 09:39 AM
ChrisBarrington_Brown
New Contributor II

Hi,

I have a set of Geoprocessing Packages, authored in Python in Pro 2.3 which work well with Local Server 100.6.  They fail (fatal crash) when run under 100.9 (which I want to upgrade to, and use Runtime 100.10, if I can).

I re-packaged the Geoprocessing tools in Pro 2.7, using both 'All version' and 2.6, which is the version advertised as being compatible with Local Server 100.9, without success in either case.

Searching Release Notes for 100.8 and 100.9 don't yield any breaking changes.

I have found no sensible error messages in the logs.  VS 2019 reports: !message:socexit:{"error":"Worker process 'catalogfgdb_worker' exited while attempting to service request (attempt 1 of 1): endpoint='GPServer' headers={} params={jobId=j2a76b89b0beb4917a3819b76426d14ad, toolName=CatalogFGDB} res='' post=0 Crash dump path=","name":"catalogfgdb","processId":-1}. 

Attempting to put some logging into the Python (which works in Arc Pro) creates the log file but writes nothing into it before the package crashes.

Anyone out there have any experience in updating gpkx to later versions of Local Server?  Do I need to downgrade to a previous version of Pro to repackage them, and if so, which version?  Or am I missing something obvious?

Many thanks

Chris BB

0 Kudos
3 Replies
MichaelBranscomb
Esri Frequent Contributor

Hi Chris,

Are your geoprocessing packages built from models (model builder) or python scripts?

0 Kudos
ChrisBarrington_Brown
New Contributor II

Mike

Thanks, and hope you're thriving.  I've been working on this all day, and now have some things working.  The processing is all straight Python/arcpy, and all the scripts used to work in 100.6 and still work in Pro 2.7.

Between 100.6 and 100.9 Local Server has become much more picky about parameter passing.  Things which worked when, for example, a boolean was passed back as a string now no longer work, but screwing down the parameters types has got me past that for some of my gpkx.

The other areas which appear to have changed, and I'm still trying to find work-rounds are:

The handling of the Scratch area.  This works in Pro, but local server sets up its own temporary scratch areas. I used to get at those using %scratchFolder% which seems not to work any more.

arcypy ListFeatureClasses() and ListTables() with no parameters seem to cause crashes (although the docn says they should work), and don't return what I'd expect when used to get, for example, feature_type='feature'.  This may be down to the setting of arcpy.env.workspace not working as it used to, as that would definitely screw up those methods, but that's a problem for tomorrow.

Would you prefer to move this onto e-mail, then we can put up a roundup of what we find for posterity?  You might even like to put something about Geoprocessing in Local Server in the documentation....(hint, hint)

Chris BB

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Chris,

Feel free to email me to continue troubleshooting this: I would like to follow up on the issues you're seeing with `%scratchFolder%`, `arcpy.env.workspace`, and `arcypy ListFeatureClasses()` / `ListTables()`.

Thanks

0 Kudos