You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 44 Next »

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.
Look at http://www.sos-berlin.com/doc/en/scheduler.doc/xml/config.xml#attribute_supervisor for more about the remote configuration.

The outgoing ports used by JobScheduler are selected by the OS, therefore it is not predetermined which port numbers are used.

<mscgen>
// Remote configuration
msc {

 width1. "800";

config_server label"Configuration Server JobScheduler",workload labeh1. "Workload JobScheduler";

 

config_server < workload labelh1. "First Request HTTP using JETTY Port)";

  config_server box config_server[label"Register Client", textbgcolouh1. "#7f7fff",  textcolour"#FFFFFF"];
  config_server h1. workload  [label "Request every 15 minutes (HTTP using JETTY Port)"];
  config_serverh1. > workload  [label "Sending configuration changes (HTTP using JETTY Port)"];
    ---  [labelh1. "loop every 15 minutes", ID"*"];

}
</mscgen>

<mscgen>
// Remote

msc {

 width1. "800";

config_server label"Configuration Server JobScheduler",workload labeh1. "Workload JobScheduler";

 

"Configuration Server JobScheduler" box "Configuration Server JobScheduler"label"On Any change in configuration", textbgcolouh1. ";

  "Configuration Server JobScheduler"h1. > "Workload JobScheduler"  [label "Sending configuration changes wakeup signal (UDP)"];
  "Workload JobScheduler" box "Configuration Server JobScheduler"[labeh1. "If UDP signal is not recognized, the changes will be sent with the 15 minutes request", textbgcolour"#7F7f7f",  textcolouh1. "#FFFFFF"];
  "Configuration Server JobScheduler" .. "Configuration Server JobScheduler"  [label "After 30 minutes waiting for missing client"];
  "Configuration Server JobScheduler" box "Configuration Server JobScheduler"[labeh1. "unregister client", textbgcolour"#7f7fff",  textcolour="#FFFFFF"];

}

</mscgen>

How to configure the firewall?

Following the example above you have to set the follwing rules in the 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/>
  • No labels