XmlBlaster allows you to send messages over remote lines in the following ways:
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.
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.
As a plugin coder, you have to implement two interfaces
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.
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 |