Reputation: 1127
Is there a way to delete a MQTT Message from it's topic after the first subscriber has received it, so that other subscribers cannot read it?
To make this weird question clear:
I have to deal with four JBoss Instances (I have to admit that I'm absolutely NOT responsible for this architecture). They are mirrors of each other. So on every one of them runs a job which subscribes to a specific topic. The messages from this topic are persisted in a database. What I have to avoid is that the same message is persisted four times. So my idea was to create a race condition on the topic. The first job which reads the message deletes it, so that the other jobs don't receive it.
Is this possible?
Upvotes: 1
Views: 2690
Reputation: 71
If the primary aim of subscription is to persist the data in the DB, you should look at having a hook at the back end of the MQTT Broker via an API call or a direct code integration to get the data and store it.
Subscribing can always either be a overhead when you use QoS 2 for perfect storage (as mentioned in your question) or duplication possible on heavy loads when you use QoS 1 or loss of data when you use QoS 0.
Upvotes: 0
Reputation: 59608
Sort answer no, you can not "delete" messages once they have been published, the broker will deliver to all subscribers nearly instantly.
Longer answer, what you are looking for is something called shared subscriptions. This allows a group of clients to subscribe to a topic as effectively a single unit and a message is only delivered to one of the group. This is intended for load balancing. Shared subscriptions will be added to the MQTT spec as part of v5.
Currently a number of brokers have implemented this feature (each broker has implemented it slightly differently so you can't seamlessly switch between broker implementations until v5) as a value add feature. I believe the following brokers have some version of shared subscription support, there may be more:
Upvotes: 5