Figure 1
-The Message Publisher sends messages to the queue in the borker. This is similar to a PUT Http request where the client sends new content to the the server. The message thus obtained from the Message Publisher is appended to the target queue. The messages in the queue are maintain persistently.When a Message Listener establishes connection with the queue and requests for messages,they are forwarded to the listener. Again this interaction is similar to a GET Http request.
+The Message Publisher sends messages to the queue in the broker. This is similar to a PUT http request where the client sends new content to the the server. The message thus obtained from the Message Publisher is appended to the target queue. The messages in the queue are maintain persistently.When a Message Listener establishes connection with the queue and requests for messages,they are forwarded to the listener. Again this interaction is similar to a GET http request.
A detailed description of each of these three units follows.
Qpid Message Publisher:
-Event logs for jobs submitted with Condor are available at the SchedD. These log files are rotated over to maintain the latest 'X' event logs. A system that would read these event logs and persistently forward these logs is the core functionality of the Message Publisher.
+Event logs for jobs submitted with Condor are written by the Schedd and the Shadow. These log files are rotated over to maintain the latest 'X' event log entries. One of the ideas of the message publisher is to read and persistently forward Event log entries into the AMQP queue.
-The event log forwarder makes use of a log reader api(written by Nick).The forwarder works as a wrapper on top of the log reader api, providing control to selectively include or exclude event types of the job whose logs are to be read and forwarded.
+The message publisher uses Condor's log reader api.The publisher works as a wrapper on top of the log reader api, providing control to selectively include or exclude event types of the job whose logs are to be read and forwarded.
The challenges faced by this system are
-1:avoid loss of event logs.
+1:avoid loss of log entries.
1:avoid duplicate log messages
-1:message transformation
+1:message transformation into AMQP queue format
-The above stated challenges are at the forwarder part assuming the event log reader api is consistent with these challenges too. Thus after the event logs(event type(s) can be specified) are read from the log files, it is formatted. Currently the log message can be modified to the syslogng format or the classAd format or simply made as a sequence of characters (with or without separators). The abstraction on the formatting api provides easy scope to plugin other formats.
+The message publisher solves these issues by
+*: assigning each read entry a unique ID
+*: maintaining a second message queue which is consumed by the publisher whenever the client queue is accessed. After each message consumption, the publisher makes sure that the consumed entry left the queue.
+*: asserting that messages are read in order according to their unique ID (thus noticing missing messages)
+*: persistently storing state, such that in case of a system crash the previous queue state can be restored
+*: Reformatting log events: Currently the log message can be modified to the syslogng format or the classAd format or simply made as a sequence of characters (with or without separators). The abstraction on the formatting api provides easy scope to plugin other formats. Thus the log events can be converted to messages of required format and then forwarded.
-Thus the log events can be converted to messages of required format and then forwarded.
+Forwarding could mean simply to write into another text file(locally/remotely) or send messages via a syslogng or to a messaging queue system. In this documentation we are to discuss about the interactions with a messaging system.
-Again forwarding could mean simply to write into another text file(locally/remotely) or send messages via a syslogng or to a messaging queue system. In this documentation we are to discuss about the interactions with a messaging system.
-This log forwarder is then made into a Qpid client that publishes the logs read to queues in a messaging broker.
-
-In figure 2 the various components of the Event Log Forwarder and integration with Qpid as a client publisher is given.
+In figure 2 the various components of the Event Log Publisher and integration with Qpid as a client publisher is given.
@@ -58,13 +60,22 @@
{image:condorQpidFlow.jpg}
Figure 3
+Figure 3 in words:
+
+1: Init the user/event log file
+1: Read event
+1: Format event data and create unique ID
+1: If message queue is empty, try to restore from persistent state, otherwise consume an entry from backup queue (the queue which is read by publisher itself to assure consistency)
+1: compare message ID against previous message to assert order
+1: update persistence file with new ID and send message to both queues
+1: Continue with reading the next event from the user/event log file
+1: ...
+
SOURCE CODE:
-*:Event Log Forwarder: eventLogForwarder.cpp,eventLogForwarder.h
*:Qpid Client Publisher: topic_publisher.cpp
-This Message Publisher client code is run as a condor job.
@@ -79,7 +90,7 @@
Apache Qpid implements the latest AMQP specification, providing transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support and a lot more. And Apache Qpid is extremely fast.
-More information about Qpid and its implentation,configurational and setup details can be found at
+More information about Qpid and its implentation,configuration, and setup details can be found at
[http://qpid.apache.org/]
The Qpid broker is configured to use the publisher-subscriber routing model and store messages persistently. Also the queues in the broker and their corresponding routing keys are used to initialize queues in the Qpid broker.
@@ -112,7 +123,7 @@
The integration of the event log forwarder with the messaging system is added into the condor source code as a daemon ,condor job implementation.
condor_qpid daemon:
-The qpid broker is run as a condor daemon – condor_qpid that is controlled by the condor_master.
+The qpid broker is run as a condor daemon – condor_qpid that is controlled by the condor_master.
It performs the following functions:
1:Declare queues and bind them to the exchange
