Railo task managerThe new Railo 3.0 task manager is working like a queue. It executes tasks in a certain order and recurrance. It is used by Railo internally for several different jobs. An easy example is sending an eMail. When you send an eMail you want to make sure, that the eMail is sent. When the spooler is turned off, you see an instant error telling you why the eMail could not be sent. But if you turn on the spooler for eMails, this error is never seen on a client screen. Therefore you need to check logfiles or mailfolders in order to find out what happened. In Railo 3.0 the new task manager gets invoked when Railo sends an eMail. If the eMail could not be sent, the task remains in the task manager and gets reexecuted in a certain order. There are certain different problems why eMail might not have been sent. It might be a
- short-term problem
pherhaps there was a problem in the server (deadlock) and after a second it works
That's why Railo retries it 3 times every 10 seconds
- middle-term problem
pherhaps the server is booting or busy
Railo then tries it 5 times every one minute
- long-term problem
pherhaps the server is down for certain reasons like installation of a new version or executing maintenance etc. (2 times every day)
Then Railo tries it 24 times every hour. And two times every one day.
Here are some internal jobs where Railo uses the task manager:
- Sending an eMail
- Synchronizing the cluster scope
- Synchronizing server settings remotely
- Executing scheduled tasks (yet to come)
If you click on the detail button of a task you can have a look at the following options:
So Railo sets the execution schedule firsthand and executes an erroneous task until either the retry count (interval) is exceed or the task has been executed without errors. If any of the task remain unexecuted in the task manager, you can either try to re execute or delete them. Just use the according form elements.
Instance synchronizationSince we have covered the use of the cluster scope in another blog entry, I am concentrating more on the synchronization of different Railo instances. In order to synchronize two Railo web contexts or Railo instances, they need to be connected. So in a clustered environment it is not by default the case, that Railo webs and instances are synchronized. Instance synchronization is used in order to synchronize settings made in the Railo administrators. Almost all settings can be synchronized between two servers. There are of course some obvious ones that make no sense, like for instance compilation of a mapping. If errors would be thrown on the distant instance, they will not be displayed anywhere. A synchronization can be made between two distant Railo instances as long as they can "see" and "talk" to each other over the http protocol. So the more distance lies between the two (or more) partners in the synchronization the longer a synchronization might take.
You can, for instance synchronize a Railo server at work with your machine at home, if you like. As long as you are able to call the corresponding admin.cfc in the railo-context mapping.
For a simpler comprehension let's assume that we have two servers Test and Production each with several web contexts (eg. 1,2,3 etc.).
How to proceed:
First of all you need to define a connection between two (or more) Railo servers or web contexts. Let's assuume we want to synchronize webs Test1 and Production1. This can either be done in the Web Administrator under Remote/Clients for synchronizing Test1 and Production1, or in the Server Administrator for synchronizing server settings for Test and Production else wise. What you have to define in the Web Administrator Test1 is the following:
Note: In the above picture some obvious settings are missing (proxy settings).
Important to know is that the two variables defined in the Admin access section are the Web (or Server) Administrator password (of Web Administrator Production1) and the according security key of Production1. You can find this ID in the Production1 Web Administrator under the section Remote/Security Key. Important is that each web context and server context have different security keys. The key is used for the encryption of the synchronization information. If this key is not matching, the synchronization will not be successful and Railo will throw an error. Another important information is, that you can do a synchronization either only in one direction or bidirectional. In the first case the synchronization is done like a master/slave synchronization. Every change in web context Test1 will be reflected in web context Production1. Any change you do in the web context Production1 will not be sent to Test1. It will even be overwritten, if an according change is made in the Test1 Web Administrator. If you synchronize two servers bidirectional, changes in one of the administrators of the two involved servers will be broadcasted amongst them. You can even imagine to define a synchronization chain between 5 servers:
Production1 » Production2 » Production3 » Production4 » Production5
where the web context Production1 serves as the master and all other four servers are treated as slaves. If you want to synchronize all servers in a bidirectional mode, you can define a synchronization circle since when synchronizing, a Railo instance realizes, that a change was initiated by itself. So to keep all 5 web contexts in sync you connect them as follows:
Production1 » Production2 » Production3 » Production4 » Production5 » Production1.
So if a change has been made on web context Production3 it gets propagated to server Production4 and then to Production5. Now Production5 is connected to Production1 so it synchronizes the last change with it, and since Production1 is connected to Production2 and Production2 to Production3, the change lands on the web context Production3 again. Here Railo notes that the change was initiated on this server (same security key) and stops the broadcasting of synchronization messages. In this way circular references are prevented.
For the synchronization of admin settings Railo makes use of the task manager and unsynchronized changes to other servers remain in the task manager until their successful execution or deletion.
Starting own tasks with CFTHREADThe tag CFTHREAD is perfectly suited for executing background tasks asynchronously. It was introduced in Railo 3.0 and we have added a very helpful functionality to it. Next to the normal behavior which is known from CF8, CFTHREAD allows you to place your own tasks in the Railo Task Manager.
Let's assume you have a certain task to execute which you need to make sure that it gets executed like for instance creating a static image from a dynamic CMS page in order to speed up the browsing experience on a public site.
In Railo 3.0 next to the standard, we introduced two new attributes type and retryInterval, which allow you to interact with the Railo Task Manager. The type attribute can be one of the following: daemon or task. Surely by defining a thread to be of type task, Railo places it into the task manager. If the task fails (meaning that it throws an error) it remains in the task manager. If not, it will be deleted from it (execution successful).
The retryInterval attribute gives you a flexible way of defining a timetable for a non successful task. You can define one of the following:
- a timespan
- a struct containing a retry count and a timespan
- an array containing a mixture of both above