As an ActiveMQ subscriber I want to know the user name of the message publisher or any identifier on receiving the message. I'm using the MQTT protocol and the flow of message received from ActiveMQ broker will be saved according to provided identifier.
I have another constraints. The authorized publisher will just publish only the data on specified topic and will not provide any extra identifier value with the data.
Typically in this kind of situation you'd set populateJMSXUserID="true" in your activemq.xml and then when you receive the message you could just look at the JMSXUserID property. However, since MQTT doesn't support message properties this almost certainly won't work for you.
I think you'd probably have to write your own broker plugin to modify the body of the MQTT message with the necessary identifier.
Related
As I have been able to verify, in MassTransit with Azure Service Bus, each type of object consumed by a "Consumer" generates a Topic for that type regardless of whether it is only consumed in a specific "receive endpoint" (queue). When sending a message of this type with the "Send()" method, the message is sent directly to the "receive endpoint" (queue) without going through the topic. If this same message is published with the "Publish()" method, it is published in the Topic, and is forwarded to the receive endpoint (queue) from the corresponding subscriber.
My application uses a CQRS pattern where the messages are divided into commands and events. Commands use the send-receive pattern and are therefore always dispatched in MassTransit with the "Send()" method. The events, however, are based on the publish-subscribe pattern, and therefore are always dispatched in MassTransit with the "Publish()" method. As a result, a large number of topics are created on the bus that are never used (one for each type of command), since the messages belonging to these topics are sent directly to the receiver's queue.
For all these reasons, the question I ask is whether it is possible to configure MassTransit so that it does not automatically create the topics of some types of messages consumed because they will only be sent using the "Send()" method? Does this make sense in MassTransit or is it not possible/recommended?
Thank you!
Regards
Edited 16/04/2021
After doing some testing, I edit this topic to clarify that the intention is to configure MassTransit so that it does not automatically create the topics of some types of messages consumed, all of them received on the same receive endpoint. That is, the intention is to configure (dynamically if possible, through the type of object) which types of messages consumed create a topic and which do not in the same receive endpoint. Let's imagine that we have a receive endpoint (a queue) associated with a service, and this service is capable of consuming both commands and events, since the commands are only dispatched through Send(), it is not necessary to create the topic for them, however the events that are dispatched via Publish(), they need their topic (and their subscribers) to exist in order to deliver the message and be consumed.
Thanks in advance
Yes, for a receive endpoint hosting a consumer that will only receive Sent messages, you can specify ConfigureConsumeTopology = false for that receive endpoint. You can do that via a ConsumerDefinition, or when configuring the receive endpoint directly.
UPDATE
It is also possible to disable topology configuration per message type using an attribute on the message contract:
[ConfigureConsumeTopology(false)]
public interface SomeCommand
{
}
This will prevent the topic/exchange from being created and bound to the receive endpoint.
While I can understand the desire to be "pure to the CQRS mantra" and only Send commands, I'd suggest you read this answer and take it into consideration before overburdening your developers with knowing every single endpoint in the system by name...
Is there any way to check a published message if no consumers are created? Now I just have a project which publishes events and I can see that they are published by checking exchanges created in RabbitMQ. But I'm not sure if there is a way to check the message content from the Rabbit MQ interface if there are no consumers. Maybe is it better to cover a publish logic with a unit test to check that a message with correct content is published?
You can specify an alternate exchange for published messages, and those messages will be delivered to the alternate exchange if no other exchanges are bound. You can then bind that an exchange to a queue to retain those messages if there are no subscribers.
Alternatively, you can specify the Mandatory flag on the published message, and the Publish call with throw an exception if there are no exchanges bound.
Alternate Exchange Unit Test
Mandatory Unit Test
Validation ("checking") of message content is a client function, and cannot be performed in the message queue itself. It either must be performed prior to publish (trust the publisher) or it must be performed immediately after dequeue but before processing (don't trust the publisher).
I have several exchanges that are dumping messages into a single queue for consumption by a client app. When the messages are received, I'd like to be able to see the exchange the message was originally published to so I can add some metadata to the object. Is there anything I can look at in the message properties that can tell me where it came from?
The AMQP 0-9-1 specifications include the name of the exchange the message was published to in the basic.get_ok answer of the basic.get method.
Therefore, you should be able to retrieve such information. It just depends on the client you are using and to what degree it honors the AMQP specifications.
Suppose I have an application fed by a MQ queue. When the application receives a message that contains errors, the application itself pushes the received message to a certain invalid message queue.
My question is: what is the recommended way to have the receiving application append the failure/rejection reason to the message pushed on the invalid message queue? Some solutions come to mind, but I'm unsure which one is considered "best-practice":
(ab)using a standard header field
adding a custom header
encapsualting the message in another message
If all that you need is to place a reason code in the message, use the MQMD.Feedback field with one of the standard reason codes. In WMQ v7.0 or later, the application can set any number of message properties which are then readable both with JMS semantics and native WMQ API calls. It is up to you to define the taxonomy for naming the application-defined properties.
If the message is requeued to the Dead Letter Queue instead of an application-owned backout queue, it is customary to prepend a Dead Letter Header to it. The MQDLH structure contains a field for the reason code describing why that the message was requeued. As a rule, applications should avoid using the DLQ in favor of an application-owned queue. When applications do use the DLQ, it is normal that they should have access to put messages there but not to retrieve messages from that queue. This is because it is a system-wide resource and messages from different applications may land there. Normally, an admin application or person with elevated access is responsible for adjudicating and disposing of messages on the system DLQ.
What are the essential differences between publishing a message using Bus.Publish and sending a message using Bus.Send? I am looking to understand how they differ and also when I should choose to use one over the other.
Publishing is used to notify multiple Subscribers of a particular event. A Publishing endpoint will have subscription storage to identify where to send messages to. Sending is typically used to issue a command to an endpoint. A command is telling the endpoint to do something and should not expect a reply(although you sometimes do want a reply and NSB supports this).
The reason you do not see a destination for Send() is that you specify the destination via configuration. In your app.config you will map message types(a whole assembly or a class) to a destination. When you do so, you do not have to provide the destination.
Bus.Publish: used when you don't know where the message is going (0 to many subscribers).
Bus.Send: when you are sending a message to a specific handler (client to server).
ususally Context.Publish() is for publishing Event Type and Context.Send() is for Command Type