Distributed jobs require a shared "jobs" folder across all servers involved. So this means a shared NAS or SAN type of location that is mounted in the filesystem by the OS so every server still believes its working with its "jobs" folder. v11 will send back the job data, but v10 requries shared jobs folder.

prefs.XML has a flag named "distributed_jobs" which when set to true, it means this server will no longer run jobs. Instead, it will choose another replicated server which has the most free memory available to run the job instead.

These other replicated servers should all have the flag "job_scheduler_enabled" set to false. They don't process and run jobs in the common shared jobs folder. They only respond to jobs that are sent to them from the main server and run them.

You can still use ServerBeat to have a pair of main servers that gives high availability to the scheduling aspect of the jobs, while having the additional replicated servers which are doing the job processing. Only servers which have their "job_scheduler_enabled" flag set to false will accept jobs for processing.

This scenario is different then a pool of job engines which is a more efficient way of doing this. RemoteJobsEngine

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-3) was last changed on 14-Sep-2024 03:42 by Ben Spink
G’day (anonymous guest)
CrushFTP11 | What's New

Referenced by
...nobody

JSPWiki