[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] ConsumableQueuePlugin

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:


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.


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