Users register for notifications via the notification client \verb'glite-lb-notify', described in Section
\ref{s:lb-notify}
-Conditions under which the notifications are sent can be specified. For example -- job XY reaches status
+Conditions under which the notifications are sent can be specified. For example -- job XY reaches state
DONE. In \LBver{1.x}, one or more JOBID's are required in the condition and only a single occurence
-of a specific attribute is allowed among ANDed conditions. More complex conditions are allowed since \LBver{2.0}
+of a specific attribute is allowed among ANDed conditions. More complex conditions are allowed since \LBver{2.0}, including specification of job owner, or requesting to receive notifications only on actual job state change. \LBver{3.0} introduces an option to deliver notification messages over OpenWire or STOMP-based messaging infrastructure.\footnote{Such as Apache's ActiveMQ.}
-The registration is then delivered to the \LB server where it is stored.
+Each registration is delivered to the \LB server where it is stored.
At the same time, the server generates a unique notification ID for the registration and returns it to the
user.
the notification ID when registering. During this period the user can attach to the server and receive notification messages,
change conditions which triger the notification, prolong validity of the registration, or remove the registration
from the \LB server.
-It is also possible to specify on registration that notification messages for a given registration are not supposed to be delivered through the notification client but through the messaging infrastructure instead.
While the registration is valid, the user is able to repeatably connect to the \LB server from different places in the
-network and continue receiving notifications associated with the given notification ID. When relying on \LB's event delivery infrastructure to deliver messages, even notifications generated
+network and continue receiving notifications associated with the given notification ID.\footnote{Should the user have opted to receive notification messages over the messaging infrastructure, then---obviously---they need to connect to the correct topic on a messaging broker, rather than contacting the \LB sever. If unsure what messaging brokers are available in your grid environment, read that information from BDII or use the \LB Server's configuration page (Section \ref{s:findbroker}).
+} Notifications generated
while the user was not connected are stored and waiting until the user reconnects.
\subsubsection{Caveats}
\subsection{HTML and plain text interface}
+
+It is possible to use a standard Web browser or a command-line tool such as \texttt{wget} or \texttt{curl} to extract information from the \LB server. Although the querying power is higly limited, the HTTP or Plain Text interface can still serve as a simple tool to access information.
+
+\subsubsection{Job ID or Notification ID as URL}
\label{simple}
Since the gLite jobId has the form of a unique URL, it is possible to cut and paste it directly
to the web browser to view the information about the job (esp. its status), e.g.
\begin{verbatim}
firefox https://pelargir.ics.muni.cz:9000
\end{verbatim}
-To list all user's notification registration curently valid on a given \LB server, use a URL constructed as in folowing example:
+To list all user's notification registrations curently valid on a given \LB server, use a URL constructed as in folowing example:
\begin{verbatim}
firefox https://pelargir.ics.muni.cz:9000/NOTIF
\end{verbatim}
\end{verbatim}
In all cases it is necessary to have the user certificate installed in the browser.
+\subsubsection{Plain Text Modifier}
Since \LBver{2.0}, it is also possible to obtain the above results in a machine readable
\verb'key=value' form by adding a suffix \verb'text' to the above URLs. For example
https://pelargir.ics.muni.cz:9000/1234567890?text
\end{verbatim}
+\subsubsection{\LB Server Configuration}
+
+As of \LBver{3.0}, it is also possible to use the HTTPs interface to retrieve essential information on \LB Server configuration. For example:
+\begin{verbatim}
+ firefox https://scientific65.zcu.cz:9010/?configuration
+\end{verbatim}
+
+Among others, the following fields may be discerned from the URL:
+
+\begin{tabularx}{\textwidth}{lX}
+\label{s:findbroker}
+\texttt{msg\_brokers} & A list of messaging brokers that \LB server uses to deliver messages.\\
+\texttt{msg\_prefixes} & A list of permissible prefixes that must be used in messaging topics.\\
+\end{tabularx}
+
\subsection{Job state changes as an RSS feed}
The \LB includes an RSS interface allowing users to keep trace of their jobs in a very simple way using an RSS reader. The parameters of the RSS feeds are predefined, so no configuration is required.
Rather than using the \LB notification API to receive messages, access the messaging infrastructure and tap into the given messaging topic (\texttt{grid.emi.lbexample} in our case).
-Note that production environments can impose restrictions on topic names. In the context of EGI, for instance, prefix ``\texttt{grid.emi.}'' is mandatory.
+Note that production environments can impose restrictions on topic names. In the context of EGI, for instance, prefix ``\texttt{grid.emi.}'' is mandatory. A full list of permissible topic may be obtained from the \LB Server's configuration page (Section \ref{s:findbroker}).
+
+Also note that in case you are unsure what messaging brokers are available in your grid environment, you can read that information in the \LB Server's configuration page (Section \ref{s:findbroker}).
\subsubsection{Example: Waiting for more notifications on one socket}
git://scientific.zcu.cz / jra1mw.git / commitdiff