[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:
http://www.xmlBlaster.org/xmlBlaster/doc/requirements/mime.plugin.access.sql92.html
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="_org.xmlBlaster.engine.mime.regex.GnuRegexFilter.metadata"
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.
regards
Marcel
Saluti
Michele
--
http://www.xmlBlaster.org