From da7718ef463775acc7d6fbecf2d64c1bbfc39fd8 Mon Sep 17 00:00:00 2001 From: Justin Ross Date: Tue, 19 Apr 2016 23:11:13 +0000 Subject: QPID-7207: Remove files and components that are obsolete or no longer in use; move doc and packaging pieces to the cpp subtree git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1740032 13f79535-47bb-0310-9956-ffa450edef68 --- qpid/cpp/docs/book/src/old/InfoPlugin.xml | 261 ++++++++++++++++++++++++++++++ 1 file changed, 261 insertions(+) create mode 100644 qpid/cpp/docs/book/src/old/InfoPlugin.xml (limited to 'qpid/cpp/docs/book/src/old/InfoPlugin.xml') diff --git a/qpid/cpp/docs/book/src/old/InfoPlugin.xml b/qpid/cpp/docs/book/src/old/InfoPlugin.xml new file mode 100644 index 0000000000..aebcd08c02 --- /dev/null +++ b/qpid/cpp/docs/book/src/old/InfoPlugin.xml @@ -0,0 +1,261 @@ + + + +
+ +OSGI Info Plugin + + The Info OSGI Plugin was developed as a mean of monitoring the qpid broker startup/shutdown + times along with selected JVM and OS details. It was written as a OSGI plugin so it can be + used as needed. + + +
+ How it works + Assuming the plugin is deployed, upon the Activator invocation (which happens when OSGI + loads the bundles), the plugin looks for its configuration file. If the file cannot be + found, the plugin does not perform any operation and will silently exit. If the + configuration is found, it is loaded and parsed. A predefined set of data is collected and + messages are generated as per the configuration templates (see below for details). + Further, the messages are sent using one of the supported protocols (currently http + post and soap) to the configured destination. The same scenario takes place on the plugin + unload phase which usually takes place upon broker shutdown. +
+ +
+ Data Gathering + +The info plugin collects a pre-defined set of data, and generates a message according to a template +defined in each section of the ini file. Data can be of 2 categories: + + + JVM specific + + + application specific + + + + +Each data has a variable name associated which can be used for the message generation template. +The convention chosen for template is: @[variable (in uppercase)] (eg @IP, @PORT) (see configuration section +for message examples). + + +The following application specific info are gathered (variable names in round brackets): + + + + The JMX Port the application is listening to (jmxport) + + + The Port(s) the broker is listening to, comma delimited (port) + + + The Broker Version (version) + + + The key store path (KeystorePath) + + + The Plugin Directory (PluginDirectory) + + + The QPID work directory (QpidWork) + + + The JMX Principal Database (JMXPrincipalDatabase) + + + + +The following JVM specific info are collected (variable names in round brackets): + + + + Hostname (hostname) + + + IP address of the current machine (ip) + + + Number of CPU cores (CPUCores) + + + Maximum memory (Maximum_Memory) + + + Free Memory (Free_Memory) + + + Java Class Path (java.class.path) + + + Jave Home (java.home) + + + Java VM Name (java.vm.name) + + + Java VM Vendor (java.vm.vendor) + + + Java VM Version (java.vm.version) + + + Java Class Version (java.class.version) + + + Java Runtime Version (java.runtime.version) + + + OS Architecture (os.arch) + + + Sun Architecture Data Model (sun.arch.data.model) + + + User home directory (user.home) + + + User Name (user.name) + + + User Time Zone (user.timezone) + + + +
+ + +
+ Plugin Configuration + +The plugin configuration file is currently hardcoded to be: $QPID_HOME/etc/qpidinfo.ini +We plan to provide a mean to change the configuration by using system property (eg -DInfoPluginConfig) but +currently this is not available. + + +As it might be useful to send more than 1 message, eventually to different destinations, +we chose an ini file layout for the plugin configuration that consists of a global section +and set of individual sections, one for each message to be sent. + + + The configuration file has a global section composed of any key-value pairs placed before the start + of an ini-type section (eg [section]). The role of the global section is to provide a set of values + that would be inferred in each subsequent section. Any section from the config file can override any + global variable by specifying the respective key-value pair inside. + + The key protocol is mandatory, the plugin will not work if protocol=soap or protocol=http is + not specified. For soap, we expect the following keys to be present: + + soap.hostname + + + soap.port + + + soap.path + + + soap.envelope + + For http the following keys have to be present: + + http.url + + + http.envelope + + The names are self-explanatory, please see the example below. The protocol + key cannot be overwritten in the sections and it has to be chosen initially. +
+ +
Example Configuration + +For soap messages, we will abbreviate the XML header by omitting the namespaces in the config, +in order to be more readable. A minimal correct XML for the soap envelope would be + + + + ...some content... + + ]]> + + + NB. On the ini file, there can be no text wrapping for any entry (as above), the whole text should come into + a single line, irrespective of how long it is. + + + + +@ACTION-@VERSION + +[Message2] +soap.hostname=host2 +soap.port=9090 +soap.path=/axis1/services/Info +soap.envelope=@ACTION-@VERSION from @IP:@PORT + +## End of File +]]> + + + +and another example, this time using http: + + + + + + + The ini file is supporting comments starting with # or ; anywhere in the file. + The global section is considered to be the first set of lines from the ini file before the first [Section] encountered. + +
+ +
+ + + -- cgit v1.2.1