Job Processor Updates in 2014

In an effort to address some long standing Job Processor issues, some major changes were made in 2014.  At the time of this writing, there are still some issues being worked on, so be sure to read the workarounds at the bottom of the post.  But let’s start with the good news.

All settings are in .vcet.config

In previous releases, you would have to update the XML in JobProcessor.exe.config so that it knew about your custom job types.  This was an annoying extra step in deploying you plug-in.  For Vault 2014, the .vcet.config format was overhauled (along with the loading mechanism for plug-ins) so it was a good time to slip in a feature that allowed Job Processor to read the job types directly from .vcet.config.

The new .vcet.config allows for meta-data in the form of key/value pairs.  Job processor looks for keys that start with “JobType” and associates those types with your plug-in.  You can have as many types as you want, just make sure to keep the key names unique.  Name your keys like “JobType1”, “JobType2”, “JobType3” and so on.

Example (the parts in red are what you edit in your project):

More command line options

You can never be rich or have too many command line options.  In 2014, you can now set username, password and server from the command line using -u, -p and -s respectively. If you are using Windows authentication, use -w.

Example:  JobProcessor.exe -u Administrator -p pwd123 -s MyVaultServer
Example:  JobProcessor.exe -w -s MyVaultServer

Connectivity.JobProcessor.Delegate.Host.exe

To make JobProcessor.exe more stable, all the unstable operations were moved to a different process.  All plug-ins now run in Connectivity.JobProcessor.Delegate.Host.exe, that way if a job crashes or leaks memory, the problem can be handled.  And by “handled”, I mean that JobProcessor just kills the delegate process and starts another one.  In fact, JobProcessor will periodically kill and restart the delegate just to be on the safe side.

So what does this mean for your plug-in…

• To debug, you need to attach to the running  Connectivity.JobProcessor.Delegate.Host.exe.  You can’t launch this process on your own.  If you run against JobProcessor.exe, your breakpoints won’t activate.
• If you are saving data in memory, keep in mind that the entire process may be killed and restarted.
• Only one delegate exe will be running at any given time.  And, jobs are still run single-threaded.  So you don’t have to worry about your code running in parallel with other jobs.
• The OnJobProcessorStartup and OnJobProcessorShutdown events trigger on the startup and graceful shutdown of the delegate process.  If there is a crash, there may not be a shutdown event.

Open issues and workarounds

Problem: AcquireFiles hangs when running inside of a job.  You may see errors like “Cannot evaluate expression because the current thread is in a sleep, wait, or join”.
Cause:  The VDF was initialized as a UI app, which is the default setting.  We are working on a fix.
Workaround:  While the fix is being worked on, you can set the VDF to non-UI mode with the below line of code.  It won’t hurt anything if multiple plug-ins call this code.  And the code won’t harm anything after the fix is released.

Autodesk.DataManagement.Client.Framework.Library.Initialize(false);

Additional Information:  Deadlock
using AcquireFiles() Vault 2014