Common Issues with the Distributed File Server Worker

A Distributed File Server Worker is set up for "RemoteSiteA" and the worker agent is selecting this worker to process jobs for data that resides on the master site. How can this be prevented?

When the Publisher determines the site location of the content being published, it then looks for a matching site in the authentication file. In this case, no match was found and the default auth.property is used. For example, assume the authoring application is Creo Parametric. The publisher looked for the property auth.master.PROE in auth.properties. Since the property does not exist in the file, the worker agent selects any worker configured for Creo Parametric in this case.

To resolve this issue, setup Distributed File Server Worker(s) for the master site to process all content that has been synced to the master as the owning site. The property auth.master.<Authoring Application> needs to be added to the authentication file, and the worker rule has "master" as the rule.

A publishing attempt fails with the message No Distributed File Server Worker to process job, removing request from queue in WVS Job Monitor > Job Detail. What does this mean?

The Publisher found a matching site name in the authentication file auth.properties and has communicated this site name to the worker agent. However, the worker agent was unable to find a Distributed File Server Worker that has a matching rule for that site name. There are two possible reasons for this:

• The Distributed File Server Worker that was selected to process the job is offline, and there are no other workers with a rule as the site name that could process the job.

Publishing jobs on a specific File Server site are not sent to a dedicated Distributed File Server Worker when there are embedded spaces in the File Server name.

The Distributed File Server Worker does not recognize embedded spaces in the File Server name. If a File Server is configured in Windchill with a name such as "Fileserver two", then publish jobs from this File Server doesl not use the File Server Worker. To fix this problem, in the auth.properties file, you can escape the space in the file name, since this file is a Java Properties file. In the above example, the fix looks like this:auth.Fileserver\two.PROE=w.worker.remote:password In the case of the distrule in the agent.ini file, the space can be left in, since the code removes spaces when doing distrule comparison checks.

The worker is not calling the Upload to File Server Hook. What could be causing this?

There are several possible reasons why the hook is not getting called. Review the worker log file, which can provide clues as to why the hook does not execute. Examine the following:

• Check the directory path to the Upload to File Server Hook startup script in the recipe file. Ensure that the path is correct and that the directory separator is a backward slash and a forward slash. (\/).

• Check to be sure that the correct recipe file was configured to execute the Upload to File Server Hook. To determine this, look at the worker startup script and see what recipe is used. Be sure this is the recipe file that is configured to call the hook.

How do I control what Visualization files the Upload to File Server Hook uploads to the file server?

Refer to the description of the property cadagent.filetypes.uploadtofileserverhookexclusions in the wvs.properties table in Visualization Service Properties.