|Topic||XmlBlaster provides a plugin to control message delivery to remote destinations|
XmlBlaster has a plugin interface to control the dispatcher framework. This requirement describes one plugin realization which is free configurable to control message delivery to remote destinations.
Probably you should first read the delivery.control.plugin requirement (see link below) to get the big picture and then proceed with the description of this specific plugin implementation.
What can this plugin do for you?
The plugin supports a set of actions. You configure the wanted behaviour and switch the actions by sending specific status messages to the plugin. The supported actions are:
Now lets have a look at how the plugin works:
Messages are coming from the left hand side into the xmlBlaster core. If a client has subscribed to messages they will be forwarded to the callback queue (see green arrows in drawing). Naturally the dispatcher framework would take the messages out of the callback queue and deliver them directly to the client with whichever protocol the client wished (like CORBA or XmlRpc).
As the client has requested to use the plugin in his connectQos, all messages from the callback queue are intercepted by the plugin and inspected. Depending on the configuration of the plugin the messages are handled as requested. The possible actions are send, queue and destroy each of them can have the additional action notifySender.
Messages which are queued are put in a plugin owned hold back queue (see red arrow). If the plugin state later changes to send them they are flushed back to the update queue to be delivered. You may wonder why they are not directly put into the dispatcher - this is because of the dispatcher framework does not know anything about our plugin implementation details, that the plugin has implemented an own queue. The dispatcher only knows how to deal with its update queue.
There are two events which change the plugin state, and further a new plugin configuration command reconfigures the complete plugin on the fly.
How to configure the plugin?
The priority of each message is the input parameter of the decision. The priority of a message is set by a publisher when sending the message away. Depending on the priority and the current state of the dispatcher connection and of the state messages an action is chosen. The action determines what happens to the message - if it is queued, destroyed or forwarded.
The following drawing shows a typical configuration:
How does my status message look like?
In the above configuration you have specified the message oid to _bandwidth.status
and the content to e.g. 64k.
The plugin parses your above configuration and automatically subscribes to all
given message oids.
If your client is a router, you can for example write a little perl script which queries the router state and publishes this as a status message to xmlBlaster.
How does the notify message look like?
If you have configured an action='...,notifySender', all publishers of message which match this action receive a PtP notification message.
This notification message has the same message oid as the published message but an empty content. You can query the reason for this PtP message in the state of the update() QoS:
<qos> <state id='queue' info='Notification about special message treatment in plugin DispatchPlugin[Priority], dispatcher state=64k'/> <sender>_PriorizedDispatchPlugin</sender> <priority>6</priority> </qos>
Can i use many plugins simultanous?
You can load this plugin multiple times in one xmlBlaster server instance, where every instance has another configuration. The clients connecting xmlBlaster can choose which variant they want to use.
Note that one client can not use more than one plugin at the same time.
How does a client choose a plugin for its connection?
A client can use the configuration parameter DispatchPlugin.defaultPlugin on command line or in its xmlBlaster.properties file. Please see configuration section below.
In normal cases, the user will configure the plugin during login with the ConnectQos the connect() QoS XML string (requirement interface.connect):
<connect> <qos> ... <queue relating='callback'> <callback ... dispatchPlugin='Priority,1.0'> ... </callback> </queue> </qos> </connect>
or as a Java code fragment:
this.connectQos = new ConnectQos(glob, name, passwd); CallbackAddress cbAddress = new CallbackAddress(glob); cbAddress.setDelay(1000L); // retry connecting every 4 sec cbAddress.setRetries(-1); // -1 == forever cbAddress.setPingInterval(5000L); // ping every 4 seconds cbAddress.setDispatchPlugin("Priority,1.0"); // Activate plugin for callback only this.connectQos.addCallbackAddress(cbAddress);
For coding examples please look into the testsuite, links are provided below.
These parameters allow to configure the dispatch plugin.
NOTE: Configuration parameters are specified on command line (-someValue 17) or in the
xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
This page is generated from the requirement XML file xmlBlaster/doc/requirements/dispatch.plugin.priorizedDispatch.xml
Back to overview