CAD worker fails with "Save of file failed" error

[Dobi]

Finally got a new error in the CAD worker:

I am able to add to workspace and open the file in question with no issues on my system. 

Has anyone seen this one before?

[avillanueva]

I have little experience with UG WGM and publishing that that CAD system. Couple of things to try, some of them obvious:

• Is it all jobs or just this data set?
• Space full?
• Access rights on publisher?
• Could this be due to a rename event where the WGM tries to sync but conflicts with another file in that set?

[Dobi]

I had 3 files that showed up with this error this morning. I was able to get all of them opened with no issues on my end. On Friday I had a bunch of "failed to sync" errors.  CS346131 suggested to clean up the .wf and .ws folders and things have been working since then. Then this "failed to save" showed up. I did the same .wf and .ws wipes and was able to get things republished. 

Not sure what would cause this. 

[avillanueva]

I often "reset" worker files, purging old files and clearing workspace. Don't forget the FTP root folders. Is it working again?

[Dobi · Accepted solution]

After a tech support call, reinstall of WGM and confirming that everything ought to be working: the issue was with the particular file. After the first failure, though, NX was not able to recover on that machine and the subsequent jobs failed. 

There is a known issue (apparently) with CreoView Adapters and NX files that are renamed or Saved As from existing that may have been at play here but while on the call with tech support we weren't able to replicate the issue with a different file that was renamed. 

[buenosroas]

Can you elaborate on the issue regarding CVA, NX, and renamed files, please? We're also seeing the same behaviour from time to time. It would be interesting to dig a little deeper and see if we could find a viable workaround or best practice for files we're renaming or using save as on. Do you know if it has an SPR or Article related to it that I may look further into?

To us it seems like it may be instability on the worker since a resubmit of the same (failed) job later some times complete successfully. 

[Dobi]

It's a bit vague still... but I'll do my best:

The end solution was to add an abort line to the recipe files for the NX workers and also decrease the number of jobs between restarts. 

adapter/abortErrorList=13032

adapter/exitCommandCount=10

I wish I knew the root cause but that seemed to have gone undetermined because, seemingly like you've seen yourself, I would be able to resubmit the same (failed) jobs on the same workers later or immediately but to a different worker and they would succeed.

PTC suggested (after getting my failed files) that there wasn't an issue with the files themselves (per se) but rather with something in the Windchill setup we have. We haven't gone down the path of evaluating what those differences may be as the solution above seems to be working for now. 

The initial call I had with tech support pointed to the files we were working with at that time as all having the commonality of being saved as from something else that may have had an issue that we were propagating. The thing with NX that could ultimately be is in how some models are referenced or how they use WAVE reference. Not all types of references are supported. 

I'm happy to update this thread as I learn more about it but since putting in or editing those two lines in the recipe files, I haven't had a single fail with that failure signature... even for the files that reliably failed. 

Not sure if there is an SPR but I'll ask and add it here for reference if there is one. 

[buenosroas]

Thanks! We used to have exitCommandCount set to 1, so that it would in fact restart after every job. This was disabled during our latest upgrade, but I think that we will have to implement that again for the sake of stability. I republished some of our most failing models and drawings with this setting on our test server and saw that each publish job would then complete successfully. 

I'd spent a lot of time to look through and test different Part Cleanup settings, and they seemed to work well up to the point where the jobs started failing again. The worker restart for each job is so far the only (and easiest) method to get consistent Successful job completions. We will take a small hit on worker efficiency with this setting, but it beats failing publishing jobs hands down. 

[Dobi]

News is that no SPR but this line was added yesterday to the CS346131 article on account of this troubleshooting.

I'd be curious to know how the 13032 failure contributed to NX disconnecting from WWGM but I have other things to do at the moment 🙂 

[buenosroas]

Thanks again! We've been on track to test clearing the worker cache in between each publishing before. I think that I will try a setup of this on our test server worker at some point, but like you say it's not among the top priorities right now. I really appreciate that you took the effort to bring this to my attention.