Type	NEW
Priority	LOW
Status	CLOSED

Topic	XmlBlaster has a plugin which tells a topic to behave like a queue, i.e. that every message update is delivered and consumed only once.
Des cription	The ConsumableQueuePlugin is an implementation of the msgDistributor plugin. Every message published on a topic which has a ConsumablePlugin defined as its message distributor, is distributed only to one single subscriber and immediately consumed. This guarantees that every message is delivered and consumed only once. How does this work ? The administrator makes sure the xmlBlaster.properties file contains the registration of the consumable plugin. The publisher sets the msgDistributor attribute in the TopicProperty of the PublishQos to the ConsumableQueue key. From that point on the distribution of published messages is delegated to the ConsumableQueue plugin. The distribution itself is done in another thread to release the publisher thread immediately and before messages are distributed. Once a topic has a ConsumableQueuePlugin, and a new message is published on it, the plugin sends the message to the first available subscriber. First available subscriber means in this context a subscriber which has a callback server which is reachable (i.e. on the server side the dispatcher is alive). A polling dispatcher as the result of a client which is currently unavailable would not be considered. Simple load balancing can currently only happen if the update method (on the client side) acknowledges the message but processes the message in another thread. This way the distribution thread is made free and can process the next message by giving it to the next session on the line. This is based on a round robin algorithm.
Example Java	there is a little demo script which shows how to use a ConsumableQueuePlugin. Go to the demo/javaclients/script directory and invoke: java javaclients.script.XmlScript -requestFile consumableQueue.xml
Example Java	This example shows how to try the feature with command line clients. Start all processes in a different console window, hit enter to publish another message and try killing arbitrary subscribers: java org.xmlBlaster.Main java javaclients.HelloWorldSubscribe java javaclients.HelloWorldSubscribe java javaclients.HelloWorldSubscribe java javaclients.HelloWorldPublish -numPublish 50 -consumableQueue true
Configure	The first step to do when configuring this plugin is to register it by assigning a name to it. This is normally put into the xmlBlaster.properties file which is read by the server. The name has the structure PluginType[instanceName][instanceVersion] as stated in the first row in the table below. The xmlBlaster.properties.template coming along with the distribution contains that already. The second step is to define a default plugin to be used when the client does not specify anything explicitly. The default configuration has this set to 'undefined', i.e. a topic has per default no MsgDistributorPlugin configured. Property Default / Example Description Implemented MsgDistributorPlugin[ConsumableQueue][1.0] org.xmlBlaster.engine.distributor.plugins.ConsumableQueuePlugin Register your plugin MsgDistributorPlugin/defaultPlugin "undef" Specify the plugin to use as a default. When the client does not define anything in its TopicProperty.setMsgDistributor then this plugin instance is used. 'undef' means no MsgDistributorPlugin is used. When publishing a topic for the first time (or when doing an administrative publish), you can specify which plugin to use for the distribution of the message. In java you would do it like this: ... PublishQos pubQos = new PublishQos(global); TopicProperty topicProp = new TopicProperty(global); topicProp.setMsgDistributor("ConsumableQueue,1.0"); pubQos.setTopicProperty(topicProp); MsgUnit msgUnit = new MsgUnit(new PublishKey(global, someOid), someContent, pubQos); global.getXmlBlasterAccess().publish(msgUnit); ... 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.engine.distributor.I_MsgDistributor
See API	org.xmlBlaster.engine.distributor.plugins.ConsumableQueuePlugin
See API	org.xmlBlaster.util.plugin.I_Plugin
See REQ	msgDistributor.plugin
See REQ	util.property.env
See TEST	org.xmlBlaster.test.distributor.TestConsumableQueue

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

Back to overview