IT:Queues - Revision history

Angus: Marked this version for translation

2014-11-07T14:35:42Z

Marked this version for translation

Angus at 14:35, 7 November 2014

2014-11-07T14:35:18Z

Catriona: Marked this version for translation

2014-09-02T10:07:23Z

Marked this version for translation

Catriona at 10:06, 2 September 2014

2014-09-02T10:06:59Z

Angus: Created page with "=Queues= The following queues are used within iSIKHNAS to transfer tasks between different elastic servers. ==emailinput== Messages are placed on the queue by the email parsi..."

2014-09-02T08:35:47Z

Created page with "=Queues= The following queues are used within iSIKHNAS to transfer tasks between different elastic servers. ==emailinput== Messages are placed on the queue by the email parsi..."

Halaman baru

=Queues=
The following queues are used within iSIKHNAS to transfer tasks between different elastic servers.

==emailinput==
Messages are placed on the queue by the email parsing script on the messaging server, and collected by the processing daemon on the processing server. Messages include the '''To''' and '''From''' addresses and a reference to the location (in S3) of any attached Excel file.

==emailouput==
Messages are placed on this queue by different servers wanting to send an email. They are collected by the email sending daemon on the messaging server. Messages include the '''To''' address, subject, message content, and a reference to any attachments in S3.

==reportrequest==
The report creation daemon listens to this queue and generates output reports.

==deadletter==
This is a special queue for messages which could not be processed. Normally, un-handled messages are placed back on the queue so another server can process them. However, after 20 attempts, if the message has not been successfully processed, there is either a problem with the message format or with the server. In this case the message is placed in the deadletter queue. Messages from the deadletter queue are reported regularly to administrators for debugging purposes.

@@ Baris 13: / Baris 13: @@
 The report creation daemon listens to this queue and generates output reports.
-==updatesidecar==
+==updatesidecar== <!--T:6-->
 Changes made on the live system trigger a function which places the new data in this queue. A daemon on the training server inserts or updates the new data into the Sidecar database

@@ Baris 12: / Baris 12: @@
 ==reportrequest== <!--T:4-->
 The report creation daemon listens to this queue and generates output reports.
 ==deadletter== <!--T:5-->
 This is a special queue for messages which could not be processed. Normally, un-handled messages are placed back on the queue so another server can process them. However, after 20 attempts, if the message has not been successfully processed, there is either a problem with the message format or with the server. In this case the message is placed in the deadletter queue. Messages from the deadletter queue are reported regularly to administrators for debugging purposes.
 </translate>

@@ Baris 1: / Baris 1: @@
 <languages/>
 <translate>
-=Queues=
+=Queues= <!--T:1-->
 The following queues are used within iSIKHNAS to transfer tasks between different elastic servers.
-==emailinput==
+==emailinput== <!--T:2-->
 Messages are placed on the queue by the email parsing script on the messaging server, and collected by the processing daemon on the processing server. Messages include the '''To''' and '''From''' addresses and a reference to the location (in S3) of any attached Excel file.
-==emailouput==
+==emailouput== <!--T:3-->
 Messages are placed on this queue by different servers wanting to send an email. They are collected by the email sending daemon on the messaging server. Messages include the '''To''' address, subject, message content, and a reference to any attachments in S3.
-==reportrequest==
+==reportrequest== <!--T:4-->
 The report creation daemon listens to this queue and generates output reports.
-==deadletter==
+==deadletter== <!--T:5-->
 This is a special queue for messages which could not be processed. Normally, un-handled messages are placed back on the queue so another server can process them. However, after 20 attempts, if the message has not been successfully processed, there is either a problem with the message format or with the server. In this case the message is placed in the deadletter queue. Messages from the deadletter queue are reported regularly to administrators for debugging purposes.
 </translate>