Publishing jobs can sometimes fail, or have unexpected results. For example:
There are a few reasons why a publish job could fail:
Once a Publish Job has been submitted, the submit button is dimmed. Another publish job cannot be submitted until the previous job is complete. It is possible to submit an upload job even when another upload job is running. However, it stays in a standby state until the previous job is complete.
Jobs, such as publishes, server directory uploads, and so on, operate as independent threads running on the server. The UI does not have direct access to these processes. Instead, it submits a stop request to the thread. So, when the thread gets to a point in its processing loop where it checks for the request, it terminates. How long it takes for a process to get to one of those checkpoints depends on the type of job running. It also depends on the specifics of that instance of the job.
The "Stop" functionality sets a "JOB_STATE_STOPPING" for the job that will interrupt the job the next time that application looks at the state. The timing is dependent on how often and when the process checks the state.
The IR and IS publishes have four points that the state is checked:
In addition the IS Publish checks periodically during main manifest creation for interrupts.
With IR publishes with Vignette Format, much of the time of the publish is creating the derived output vignettes for the formats. There is no check of interrupts in this area. It is hard to knock a job down for some time if there are many to produce for the job.
Video Publishes has two points that are checked:
The Upload from Server Directory job (Upload via FTP) has various points that it checks to the job stop state during the traversal of the folder tree. However, if the client has a flattened folder with no subfolders, it could never stop processing once we have the list of files from the folder to upload.