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

Re: [xmlblaster] ConsumableQueuePlugin

Michele Laghi wrote:
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:


Feature enhancement:

We could easily extend all our mime plugins.
Currently they parse the content of the message (they do
a "full text search").

A client could add a


clientProperty to its publish QoS which contains message instance
specific meta information (here for the regex plugin).

Note that this is not the topic meta information (delivered in the <key>)
which is immutable during the topic life time.

Now this clientProperty meta information is checked by the
mime plugin instead of the content.
If the clientProperty does not exist the plugins behave as before.

This is easily implemented and would support any
imaginable filter use case.

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.

Usually the latency in xmlBlaster with topic creation and deletion is about 100 msec, without topic creation it is much lower. If the messages are persistent the harddisk access slows it down further. Just measure it with your setup to be on the safe side.