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 connection for port 4440 of the master and incoming udp for port 5000 of your slave.
The outgoing ports used by JobScheduler are selected by the OS, therefore it is not predetermined which port numbers are used.
How to configure the firewall?
Following the sample above you have to set the follwing rules in you firewall:
- allow incoming TCP from slave to master at port 4440
- allow incoming UDP from master to slave at port 5000
Detailed workflow of remote configuration
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 file list
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:4444]
On a Linux system you'll get another message code, but the same message.
What becomes if something was changed in the remote folder?
(4) signal changes
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.
(2) send file list
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/
Request the configuration from the master via xml command
It is also possible to get the current configuration from the master with the xml command
<check_folders/>