Intermittent Geoprocessing Error

[GeorgeFaraj]

Does anyone know why executing the geoprocessor (from a local geoprocessing service) results in intermittent exceptions being thrown? It will fail and succeed intermittently with the same parameters being passed.

Is there anything I can do to prevent this from happening?

ESRI.ArcGIS.Client.Tasks.ServiceException was caught
  Message=Unable to complete operation.
  Source=ESRI.ArcGIS.Client
  Code=400
  StackTrace:
       at ESRI.ArcGIS.Client.Tasks.TaskBase.Request(String url, Dictionary`2 parameters, Boolean forcePost)
       at ESRI.ArcGIS.Client.Tasks.Geoprocessor.Execute(List`1 parameters)
       at TAGISViewer.GeoprocessingDialog.<DoRunSelectedTool>b__0() in C:\Source\PACS.NET\Source\Development\PACS.NET-1.0\Washington\TAGISViewer\Dialogs\GeoprocessingDialog.cs:line 410
  InnerException:


Details:
Error executing tool.: ERROR 000210: Cannot create output C:\Users\gfaraj\AppData\Local\Temp\arcgisruntime_11992\geotools\jobs\_\j5c946bbf0d954cf19138cffb3190f140\scratch\scratch.gdb\Buffer487
Failed to execute (Buffer).
Failed to execute (BufferModel).
Failed to execute (BufferModel).
Failed to execute (BufferModel).

[MatthewBrown1]

Hi George,

A few users (including myself) have posted similar questions and I'm not aware that there is a definitive answer. However, there are some things you can try.

1. Capture the task/job status and retry the tool (for a limited count!) until it succeeds.


2. Execute your code on a PC/VM that has just the default Windows build i.e. no antivirus or group policies that might restrict your app writing to the temp directory. (This seems to be a common cause for ERROR 000210 and the like.)

I'd be interested if you were able to share any GPO rules you are aware of and the flavour of antivirus you use. (I have a dev laptop running a default build of 32-bit Win7 SP1 and Symantec Endpoint Protection off the network and it runs fine, however our enterprise build of 64-bit Win7 SP1 and Microsoft Forefront Endpoint Protection has the issue you describe.)

For a while, it seemed that submitJob worked better than executeAsync and that x86 Windows worked better than x64, but it seems to relate more to the user temp directory access and my current thinking is that it isn't actually a bug with the Runtime SDK.

[GeorgeFaraj]

1. Capture the task/job status and retry the tool (for a limited count!) until it succeeds.

I thought of doing this, but I hoped there was a better solution.

1. Execute your code on a PC/VM that has just the default Windows build i.e. no antivirus or group policies that might restrict your app writing to the temp directory. (This seems to be a common cause for ERROR 000210 and the like.)

It's gonna be difficult for me to do this since all machines here have an anti-virus installed.

I'd be interested if you were able to share any GPO rules you are aware of and the flavour of antivirus you use. (I have a dev laptop running a default build of 32-bit Win7 SP1 and Symantec Endpoint Protection off the network and it runs fine, however our enterprise build of 64-bit Win7 SP1 and Microsoft Forefront Endpoint Protection has the issue you describe.)

For a while, it seemed that submitJob worked better than executeAsync and that x86 Windows worked better than x64, but it seems to relate more to the user temp directory access and my current thinking is that it isn't actually a bug with the Runtime SDK.

Interesting. My anti-virus is managed through the network by my workplace, and it looks like we use System Center 2012 Endpoint Protection. I can't turn it off, apparently, but I will talk to the Systems department.

Thanks for your helpful answer, Matthew.

[MatthewBrown1]

I recommend investing in some kind of virtual machine. We use VMware Workstation for dev sandboxes and test machines that are both isolated from the network and on the domain. The software is not cheap (there is a free alternative - https://www.virtualbox.org/), you'll probably need to invest a bit more in hardware (e.g. extra RAM, HDD), and it takes time to set it all up (installation, documentation, security review, etc), but it's one of the best things we've done.

You could also ask for a retired PC, re-build it and run it off the network.

Regarding the re-running of the GP task, I also think it isn't ideal and I wonder if it could be avoided by implementing the GP services differently. I have been meaning to try using .NET 4.5 and the improved async/await but the project we are working on now needs to target .NET 4.0 to support some clients still running XP.

[MatthewBrown1]

Hi,

I've also recently had this issue in ArcGIS Desktop 10.1 SP1 (iterating in arcpy) and it made me look at the problem from a different perspective. It seems to be related to this:

Bug #NIM085826 Microsoft Forefront/System Center2012 Endpoint conflicts with file geodatabase operations.

(But I'm told that it also happens with other antivirus software.)

It seems that the antivirus scans the gdb and locks it before the workflow is finished. It is possible that adding an exclusion for *.gdb might be a solution that will keep your sys admins happy.