Type	NEW
Priority	HIGH
Status	CLOSED

Topic	XmlBlaster has a plugin interface which allows to control the message dispatch
Des cription	XmlBlaster allows you to send messages over remote lines in the following ways: From clients to xmlblaster Callback from xmlblaster to clients Between xmlBlaster cluster nodes You can configure those connections in many ways, e.g. choosing the protocol, configure the queue behavior or manipulate the fail over settings. Sometimes this is not enough. This is a use case where you may want to write a little plugin, having some specific behavior. An example plugin Please study the following illustration which shows an example for this use case. On the left there are permanently published messages. They have different priorities, most important messages are marked with 9 and nonrelevant ones with 0. On the right hand side you see two remote connections, a high performing satellite connections which supports 2 MBit/sec, and an ISDN line with only 64 kBit/sec. When the satellite connection fails, the routing hardware switches to the fallback line with the limited band width. This change of bandwidth is published to xmlBlaster as a status message. The dispatcher plugin has subscribed to status changes and receives the status message that the line dropped to 64 kBit. Now have a look at the plugin configuration. When we are on backup line (64 kBit) it is configured to hold back all low priority messages, here the priorities 0 to 6 (inclusiv), and stuffs them into the existing xmlBlaster callback queue. But the higher priority messages, here the priorities 7 to 9 (inclusiv), are still send over the backup line. When the line is fine again, the router sends a status message which contains the '2M' state and our plugin switches to send all messages, including the hold back messages in the queue. How to write my own plugin As a plugin coder, you have to implement two interfaces I_Plugin: Which allows xmlBlaster to load the plugin I_MsgDispatchInterceptor: Which forces you to implement some methods which allows you to control the message flow This is simple and straight forward (see requirement dispatch.plugin.priorizedDispatch). Note that this is only an example what you can do. The status message and priority configuration of the above example is specific for exactly this plugin. If you implement your own plugin, you can do whatever you like. The plugin intercepts the queue and the dispatcher framework and can manipulate anything which is in this scope. You could for example write a plugin which send messages at a contolled transfer rate (say 10 msg/sec or 4000 bytes/sec) or which opens an own queue and resorts the messages. For the above example exists an implementation which you can use or change to your needs, see the PriorizedDispatchPlugin link below.
Configure	Property Default / Example Description Implemented DispatchPlugin[MyPlugin][1] com.xy.MyPlugin Register your plugin DispatchPlugin[Another][1.0] com.xy.MySpecial Register your plugin DispatchPlugin/defaultPlugin "MyPlugin,1" or "Another,1.0" or "undef" Specifiy the plugin to use as a default. Default is undef that is no default plugin is loaded which is usually the correct setting: The client normally chooses on login its desired plugin by specifying it in the connect QoS NOTE: Configuration parameters are specified on command line (-someValue 17) or in the xmlBlaster.properties file (someValue=17). See requirement "util.property" for details. Columns named Impl tells you if the feature is implemented. Columns named Hot tells you if the configuration is changeable in hot operation.
See API	org.xmlBlaster.util.dispatch.plugins.I_MsgDispatchInterceptor
See API	org.xmlBlaster.util.dispatch.plugins.prio.PriorizedDispatchPlugin
See API	org.xmlBlaster.util.plugin.I_Plugin
See REQ	dispatch.plugin.priorizedDispatch
See REQ	util.property.env
See TEST	org.xmlBlaster.test.dispatch.ConfigurationParserTest

This page is generated from the requirement XML file xmlBlaster/doc/requirements/dispatch.control.plugin.xml

Back to overview