[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] ConsumableQueuePlugin
Hi Joanne, I believe answering this email also answers your question in
the previous email:
4. A different client 'Client2' publishes a msg with no specific oid
or destination:Michele wrote:
<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
6. Client1 parses for the key of the message, and uses it to
permanently erase it from xmlblaster's message store using:
If you assigned a particular oid in point 4. then this is not necessary
If I start publishing messages under the same oid, I'm don't understand why I still shouldn't erase a message even after my client has retrieved it. Let's say my client has an xpath+sql92 filter subscription for a specific oid. (Further, my client has disabled async processing by setting dispatcherActive=false. I also make arrangements so that only way my client retrieves these messages is by performing admin gets on its callback queue.) After my client gets a message, it does some processing. Now let's say I DON'T erase it from the store and for some reason my client crashes right after processing -- thereby invalidating its callback queue. Now if I restart my client 5 seconds later, connect using the same session name as before and renew the same subscription, the message I just processed in the former instance is still in the queue and ends up getting processed again. If I had deleted the message after I had processed it, then this wouldn't happen. But then I run into an
ther problem on how to delete a specific message instance without deleting the entire topic (since they all share the same oid).
The connect qos for my client uses: <duplicateUpdates>false</duplicateUpdates>
The subscription qos uses: <initialUpdate>true</initialUpdate><multiSubscribe>false</multiSubscribe><history newestFirst='false'/>
For increased redundancy support, I've deliberately set initiateUpdate=true because I want access to any messages that could have been published between the time my first client crashed and the time the second instance renewed the subscription. It is extremely important that these interim messages be retrievable by the client even if the client's subscription is made after the messages are published. But if I publish 2 messages with the same oid (but different contents) BEFORE my client actually subscribes to them, my client will only have access to the latter of the 2 messages when my client actually does subscribe. And this is understanable since: 'Further published messages with the same oid overwrite the previous message (the history depth is one)' (REQ: engine.message.html). But now, how can I utilize reusing the same oid while being able to support the redundancy I describe?
The reason why you get the same message when recovering your client
after a crash is because you choosed initialUpdate='true'. Then what
happens is that you get the last message published on that topic.
You should avoid this by setting initialUpdate='false'
Now of course you are afraid to loose messages while the client is
offline. Don't worry: as always xmlBlaster has a solution for you:
failsafe callback. Invoke on the subscriber's command line (for example):
-dispatch/callback/retries -1 -dispatch/callback/delay 5000
Then your messages (the ones you define as interim messages) are nicely
delivered to your callback queue even if you are not there. Once you
connect again you get all the messages published while you where gone.
In fact if Client1 has connected in failsafe mode (and with no session
timeout) he can go on vacation after having subscribed (and leaved
without calling disconnect) and never come back again.
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964