Re: [xmlblaster] ConsumableQueuePlugin

[Michele Laghi <laghi at swissinfo.org>]

Hi Joanne, I believe answering this email also answers your question in 
the previous email:

Joanne wrote:
> [snip]
> Joanne wrote:
>
> > > 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>
> > Michele wrote:
> > 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.
>
> [snip]
> Joanne wrote:
>
> > > 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>
> > Michele wrote:
> > 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
o!
>  ther problem on how to delete a specific message instance without deleting the entire topic (since they all share the same oid).
>
> FYI:
> 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.

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