---------- DRAFT ----------
Overview
To exchange the configuration between a master and its slaves you need to be open the incoming port for any JobScheduler installation.
Assume you have configured your supervisor JobScheduler (master) with port 4440 and your workload JobScheduler installation (slave) with port 5000.
Than you have to be open incoming tcp port 4440 for the master and incoming tcp and udp port 5000 for your slave.
The outgoing ports used by JobScheduler are selected by the OS, therefore it is not predetermined which port numbers are used.
Detailed workflow
What becomes if UDP does not work?
The master uses UDP only as an "wake-up call" to the slave to speed up the process of updating. Independently of the UDP call, the master sends the configuration from time to time to the slave.
What becomes if the slave comes up (and the master is present)?
(1) register client
First the slave establish the connection to the master and register itself. Doing this it sends the following command to the master:
<register_remote_scheduler scheduler_id="scheduler-5000" tcp_port="5000" udp_port="5000" version="1.3.2251"/>
You can see it in the scheduler.log of your master JobScheduler.
The slave acknowledge the registering with the message
(Supervisor_client 192.11.0.90/aragorn.sos:4440) SCHEDULER-950 Scheduler has been registered
(2) send filelist
Directly afterwards the master sends a list of all relevant remote configuration files to the registered slave, e.g.:
<supervisor.remote_scheduler.configuration.fetch_updated_files>
<configuration.directory name="stresstest">
<configuration.file name="order_creator.job.xml" last_write_time="2012-09-21T12:52:46.000Z" md5="7df1d94be68af8b4e26d93be876f7757"/>
<configuration.file name="order_creator.job_chain.xml" last_write_time="2012-09-21T12:52:46.000Z" md5="a544225718e4f81deaeebe8db461f771"/>
<configuration.file name="unix_job.job.xml.bak" last_write_time="2012-09-21T12:52:46.000Z" md5="e531680927dd17b7a1ed89a389bb7a82"/>
<configuration.file name="unlimited.process_class.xml" last_write_time="2012-09-21T12:52:46.000Z" md5="870a71a918e60b5635e8e363b9b6953a"/>
</configuration.directory>
</supervisor.remote_scheduler.configuration.fetch_updated_files>
(3) fetch configuration
The slave will be update its configuration fetching the files from the master.
Afterwards this register will be send every 60sec to the slave.
What becomes if the slave comes up (and the master is not present)?
The slave is not able to connect to the master and will be work with the latest configuration loaded from the master.
You will see a message like this in the scheduler.log of the slave:
ERROR WINSOCK-10061 Socket is not connected - Connection refused [connect] [192.11.0.90:4447]
On a Linux system you'll get another message code, but the same message.
What becomes if something was changed in the remote folder?
The master indicates changes in its remote folder with a UDP message send to the slave:
sending UDP command check_folders to 192.11.0.79/dialin-0.sos:5000
It triggers the execution of the command
<check_folders/>
at the slave side which cause the adjustment with the remote configuration. Independently of the UDP call, the master sends the configuration from time to time (appr. every 60sec) to the slave.
At slaves side it will be logged as follows:
sos::scheduler::directory_observer::Directory_observer::async_continue_ check configuration directory C:/ProgramData/sos-berlin.com/jobscheduler/scheduler-5000/config/live/