From 6c0aa45c07c4c7f43b1b4585c880998077ad32eb Mon Sep 17 00:00:00 2001 From: Martin Polanka Date: Sun, 6 Nov 2016 11:00:00 +0100 Subject: [PATCH] typos --- Monitor.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Monitor.md b/Monitor.md index 2aa5329..198a319 100644 --- a/Monitor.md +++ b/Monitor.md @@ -2,14 +2,14 @@ ## Description -Monitor is part of ReCodEx solution for reporting progress of job evaluation back to user in the real time. It gets progress notifications from broker and sends them through WebSockets to clients' browsers. For now, it's meant as an optional part of whole solution, but for full experince it's recommended to use one. +Monitor is part of ReCodEx solution for reporting progress of job evaluation back to user in the real time. It gets progress notifications from broker and sends them through WebSockets to clients' browsers. For now, it is meant as an optional part of whole solution, but for full experince it is recommended to use one. -Monitor is needed one per broker, that is one per separate ReCodEx instance. Also, monitor has to be publicly visible (has to have public IP address or be behind public proxy server) and also needs a connection to the broker. If the web application is using HTTPS, it's required to use a proxy for monitor to provide encryption over WebSockets. If this is not done, browsers of the users will block unencrypted connection and won't show the progress to the users. +Monitor is needed one per broker, that is one per separate ReCodEx instance. Also, monitor has to be publicly visible (has to have public IP address or be behind public proxy server) and also needs a connection to the broker. If the web application is using HTTPS, it is required to use a proxy for monitor to provide encryption over WebSockets. If this is not done, browsers of the users will block unencrypted connection and will not show the progress to the users. ## Architecture -Monitor is written in Python, tested versions are 3.4 and 3.5. This language was chosen because it's already in project requirements (fileserver) and there are great libraries for ZeroMQ, WebSockets and asynchronous operations. This library saves system resources and provides us great amount of processed messages. Also, coding in Python was pretty simple and saves us time for improving the other parts of ReCodEx. +Monitor is written in Python, tested versions are 3.4 and 3.5. This language was chosen because it is already in project requirements (fileserver) and there are great libraries for ZeroMQ, WebSockets and asynchronous operations. This library saves system resources and provides us great amount of processed messages. Also, coding in Python was pretty simple and saves us time for improving the other parts of ReCodEx. For monitor functionality there are some required packages. All of them are listed in _requirements.txt_ file in the repository and can be installed by `pip` package manager as ``` @@ -36,7 +36,7 @@ _Thread 2_ is responsible for managing all of WebSocket connections asynchronous Incomming ZeroMQ progress message is received and parsed to JSON format (same as our WebSocket communication format). JSON string is then passed to _thread 2_ for asynchronous sending. Each message has an identifier of channel where to send it to. -There can be multiple receivers to one channel id. Each one has separate _asyncio.Queue_ instance where new messages are added. In addition to that, there is one list of all messages per channel. If a client connects a bit later than the point when monitor starts to receive messages, it'll receive all messages from the beginning. Messages are stored 5 minutes after last progress command (normally FINISHED) is received, then are permanently deleted. +There can be multiple receivers to one channel id. Each one has separate _asyncio.Queue_ instance where new messages are added. In addition to that, there is one list of all messages per channel. If a client connects a bit later than the point when monitor starts to receive messages, it will receive all messages from the beginning. Messages are stored 5 minutes after last progress command (normally FINISHED) is received, then are permanently deleted. Messages from client's queue are sent through corresponding WebSocket connection via main event loop as soon as possible. This approach with separate queue per connection is easy to implement and guarantees reliability and order of message delivery. @@ -57,7 +57,7 @@ Systemd script runs monitor binary as specific _recodex_ user, so in `postinst` ``` $ python3 setup.py bdist_rpm --post-install ./install/postints ``` - to generate binary `.rpm` package or download precompiled one from releases tab of monitor GitHub repository (it's architecture independent package) + to generate binary `.rpm` package or download precompiled one from releases tab of monitor GitHub repository (it is architecture independent package) - install package using ``` # yum install ./dist/recodex-monitor--1.noarch.rpm @@ -71,7 +71,7 @@ Systemd script runs monitor binary as specific _recodex_ user, so in `postinst` ## Configuration and usage ### Configuration -Configuration file is located in subdirectory `monitor` of standard ReCodEx configuration folder `/etc/recodex/`. It's in YAML format as all of the other configurations. Format is very similar to configurations of broker or workers. +Configuration file is located in subdirectory `monitor` of standard ReCodEx configuration folder `/etc/recodex/`. It is in YAML format as all of the other configurations. Format is very similar to configurations of broker or workers. ### Configuration items @@ -126,7 +126,7 @@ You should see green **Active (running)**. ``` Alternatively monitor can be started directly from command line. -Note that this command won't start monitor as a daemon. +Note that this command will not start monitor as a daemon. ``` $ recodex-monitor -c /etc/recodex/monitor/config.yml ```