I have a problem by using fusesource code to publish mqtt messages to Apollo server.
I wrote the message publisher with the code like the following
connection.publish(topic, message.getBytes(),QoS.AT_LEAST_ONCE, true);
I also wrote the message consumer which subscribes to the topic. If I started my consumer first and then the publisher, the consumer can obtain all messages correctly. However, if I start the publisher first and then the consumer, the consumer will not receive the messages.
Also, I went into Apollo admin console and I could not find any messages in the queue. (Please see attached screen shot).
What should I do to fix this problem? I could not make my consumer running all the time and I don’t want to lose any messages from the publisher. Should not the broker (Apollo) keep all the messages when the consumers are offline? If yes, how come I could not see it?
This seems a silly question but I am pretty new to MQTT and I do need some help.
I suspect the topic is being auto deleted once there are no producers or consumers attached to the topic. To disable auto delete 'feature', add the following XML element within the virual_host config element in apollo.xml:
<topic auto_delete_after="0"/>
Future versions of apollo will avoid deleting the topic when holds a retained message APLO-319 .
This seems like a bug, since you have marked the messages as retained. However, I do not know how Apollo behaves regarding multiple retained messages on a topic. You may want to raise this on their mailing list.
Related
I'm trying to run an MQTT broker and I want to store the published data, but I need to know which user sent the message so I can store payload for each user and study them later. The problem is when two different user try to publish message on same topic I can not tell whose data it is. Is there a way to figure out the publisher of a message? I'm using Mosquitto btw.
Short answer, you don't.
MQTT messages do not contain any information about the user or client that sent it, unless you choose to encode it in the message (as part of the payload for v3.x or alternatively in the header properties for v5.0)
Longer answer:
Some MQTT brokers have plugin APIs that may allow you access to more meta data for a message. You may be able to write a plugin that will take the message + the meta data and then store them. Last time I looked, mosquitto's plugin API was only for writing authentication plugins, and did not give access to the messages themselves. But a different broker may allow this.
I'm writing a ServiceBus over MQTT protocol for a personal project.
I would basically like to subscribe every messages except the ones that comes from my instance.
I thought about doing a application side check, adding a "SenderId" property in my message.
But it has a considerable overhead in bandwidth consumption and also in compute time cause I have to check every single message if I'm the sender
I'm using basic topic family/message layout nothing complicated
I thought about using some kind of topic layout like : family/message/{senderIdHere}
But it looks like I'm wrong somewhere cause I would like to subscribe all
Here is a small example. That "EventPipeline" is somehow necessary to reduce code duplication between internal instance handling and over service bus handling
If anyone have some great hints,
Thanks by advance.
MQTT doesn't work that way, if you subscribe to a topic you normally get everything published to that topic.
The one possible option I can think of is to have everything publish to it's own sub topic e.g. family/message/{senderIdHere} and subscribe to the wildcard family/message/#
Then use ACLs to allow each user to publish (write) to their subtopic, but not be able to subscribe (read) from it. This will have the broker filter the messages for you.
Edit:
MQTT v5 introduced an option when subscribing to a topic to ignore the publisher's own messages. But this does require both the broker and the client to be using MQTT v5
How can I tell mosquitto MQTT what to do in case multiple persistent subscribers attempt to connect with the same client ID?
I accidentally ran into this situation when misconfiguring different testing environments which subscribed to the same broker. The result was that both subscribers got only part of the messages and the mosquitto log was spammed with "New connection from xxx" messages. Preferably the second subscriber would be rejected to make such a mistake apparent immediately.
I found a similar question for Solace and it seems to offer the option to either replace the older subscriber with the new one or reject the new one.
However when checking the available options for mosquitto.conf I could not see a similar option.
You don't.
The MQTT Spec says that client ids have to be unique and the correct behaviour is to kick the oldest one off and replace it with the new one.
Each event has various properties associated with it. These are translated into AMQP 0-9-1 data encoding and inserted in the message headers. The message body is always blank.link
I use the python library paho-mqtt, and there are no headers on the on_message callback and the payload is of course blank. My question is how can I know which client/queue/exchange produce the event I receive?
If this plugin can't provide the feature that I want, is there any replacement solution exists? Such as a system topic, which can provide more details about concerned event.
Update:
Sorry for my confusing question.
Since I just want to get notification when a MQTT client changes online/offline status. Now I find the interface of MQTT Client "will_set" which meets my need.
I will remove the tag "rebbitmq".
You should be using an AMQP client like Pika. There's no need to use MQTT.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I am using mosquitto mqtt client.
For example, you have users that publish and subscribe to topics. The topic actually correlates to a REsT endpoint.
Scenario 1 (typical pub/sub usage)
UserA subscribes to topic /device/123/meta
UserB publishes some data to topic /device/123/meta
by definition, this publish is broadcasted out to the subscribers
we have a script subscribed to /devices/# which knows how to save the payload for the topic /device/123/meta when it receives publish'ed data. This data is saved to the database.
Scenario 2
Someone updates data /device/123/meta via a ReST interface (or a direct DB update, the key is it's not a MQTT publish).
database is updated
a publish message is sent to the MQTT broker so that all subscribers get the updates as a payload
Scenario 2 is what I'm trying to wrap my head around. This creates a nasty feedback loop. When internal messages are broadcasted out, my script to deal with publish events from users can't differentiate between publish events originating from a 3rd party user or an internal publish event only meant to broadcast out some data (with no saving of data needed).
How should I handle this? The MQTT message is very simplistic and I'm not finding anything I can base logic off of. I'm trying to explore using the origin somehow, but no luck this far. I realize I can write plugins, but this is quite the task for mosquitto.
There is no way to distinguish where a message originated from the subscriber at a pure MQTT protocol level. Part of the point of a pub/sub protocol is to decouple publishers from subscribers.
The most portable way to do this would be to add a flag to the actual message payload to indicate that message originated from somewhere other than the actual device.
Or assuming the message is being published as a result a trigger in the database have the trigger check if the incoming message actually changed the database stored value, if the incoming messages matches the existing state of the DB then there is no need to republish it.
Mosquitto's plugin mechanism is currently only for writing authentication and authorisation solutions, but the JavaScript mosca or Java HiveMQ brokers support plugins that may be able to do what you want.