Re: [xmlblaster] ConsumableQueuePlugin

["Joanne" <jlc.xmlblaster.0504 at jambotech.com>]

[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 another 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?