Re: [xmlblaster] ConsumableQueuePlugin

[Michele Laghi <laghi at swissinfo.org>]

Hi Joanne,

Joanne wrote:
> As suggested, I'm using synchronous admin gets with consumable=false to ensure that the same message can't be processed by more than one client querying a specific session's callback queue. I've been successful in implementing a test case as a basis for my full implementation:
just one note: to make sure you are the only client getting this message 
you need to set consumable='true' (I saw you did it right in the example 
below)
> 1. Client1 logs in as with the session name myclient/1 
>
> 2. Client1 makes a subscription based on an XPATH query: 
> <key oid='' queryType='XPATH'>//key/TESTSUB[ at dest_client='chexwrapper' and  at msg_class='request']</key>
>
> 3. Client1 disables asynchrounous messaging for its session by publishing an admin command: 
> <key oid='__cmd:client/myclient/1/?dispatcherActive=false'>
>
> 4. A different client 'Client2' publishes a msg with no specific oid or destination: 
> <key oid='' contentMime='text/xml' contentMimeExtended='1.0'><TESTSUB dest_client='chexwrapper' msg_class='request'></TESTSUB></key>
> <qos><persistent/><expiration lifeTime='20000' forceDestroy='false'/></qos>
If the number of combinations in your key is limited you should consider 
assigning an oid to the message, otherwise a new topic is created which 
is time-costly.

If you have too many combinations, then I would opt for another 
solution: I would assign one single oid to all messages and pass what 
you pass in the key as clientProperties of the publish qos (in your case 
here dest_client and msg_class). In your subscription (point 2) you 
could then assign a mime plugin to query your client properties:
see the requirement:

http://www.xmlBlaster.org/xmlBlaster/doc/requirements/mime.plugin.access.sql92.html

> 5. Client1 gets the published msg after performing an admin get on the callback session queue for myclient/1: 
> <key oid='__cmd:client/myclient/1/?cbQueueEntries' queryType='EXACT'></key>
> <qos><querySpec type='QueueQuery'><![CDATA[maxEntries=1&maxSize=-1&consumable=true&waitingDelay=0]]></querySpec></qos>
>
> 6. Client1 parses for the key of the message, and uses it to permanently erase it from xmlblaster's message store using:
> <qos><erase forceDestroy='true'/></qos>
If you assigned a particular oid in point 4. then this is not necessary
> This type of implementation appears to work the way I need it to, but what are the downsides to publishing numerous messages without a specific oid and performing message handling as I described above? I was hoping someone could provide a reality check and/or confirmation on the direction of my planned implementation. In my implementation, a message must be processsed within 20 seconds of arriving at the server. Once the message is processed, it must be permanently deleted. 
Saluti
Michele


--
Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964
http://eclettic.tripod.com
http://www.xmlBlaster.org