In my application I have multiple writers that each must send their samples to a single reader. That reader logs the messages that are being sent by the writers and could potentially be a late joiner or possibly join after the writers have gone out of existence. For that reason I am using transient durability (along with the persistence service in case the writers go out of existence and still have messages that weren't received).
The challenge I am having is that the single reader must only receive the data once, even if the reader's application goes down and then comes back up. I would like to have a guarantee that once the reader acknowledges a sample it will no longer be sent to any late joiners.
Here's an example of the desired behavior: The writers write some samples and then the reader comes up as a late joiner and acknowledges the samples. The reader then goes down and comes back up, I would want that reader to not receive those same samples again.
Is there a recommended way to get this behavior?
Thanks,
Jake
I tried making my sample keyed and then calling the writer's dispose() method in the on_application_acknowledgment() callback to dispose the instance. I did that by sending the key in the AcknowledgmentInfo and setting the reliability qos to use "explicit acknowledgement". The call to the writer's .dispose() frin the on_application_acknowledgement() callback with the message (with only the key field populated) throws a strange exception:
RETCODE_ERROR:
REDAcursor_modifyReadWriteArea:!freeze read write area
[....] !failed to write sample in Commend
Is disposing an instance from the acknowledgement callback causing thread safety problems? Seems I don't have the correct approach. Any help is appreciated.
I suggest taking a look at RequiredSubscriptions and DurableSubscriptions to see if they can help. These features enable samples to be purged once they have been acknowledged.
Does this fit your needs?
Thanks,
Mike
Hi Mike,
Thanks for your help. I'd like to mark this thread as resolved as I found a solution.
I don't think that RequiredSubscriptions or DurableSubscriptions are needed currently by this part of my application since there is only one reader that needs the data. This seems it would be useful if I had a requirement that multiple readers get the data before it is disposed. I tried adding these to my xml and then removing them and it didn't seem to make a difference for my purposes currently.
I found that if the sample is keyed, then I'm able to dispose its instance immediately after I receive it from the reader. I do this by creating a writer from the application that read the incoming message and calling its .dispose() method giving it the message that was received. When I did this I found that late joiners no longer get the data.
Thanks,
Jake