Is it possible to create a queue in Service Bus and specify that when a message is published it is automatically deleted?
From your description, you want to send the message and want the message deleted automatically. Suppose what you want could be implemented with TTL.
When you use logic app to send message, there is an option Time To Live , check the doc. The description is
This is the duration, in ticks, that a message is valid. The duration starts from when the message is sent to the Service Bus.
Also you could set the queue TTL in the portal under your queue Properties.
Related
I have a Normal IBM MQ developer edition 924 installed on a ubuntu virtual machine. And have cpp code files for Publisher and Subscriber model. I created a topic and started sending messages on the topic.
The issue happens when I send a larger message on the topic, the error code of 2031(MQRC_MSG_TOO_BIG_FOR_Q_MGR) is outputted. (https://www.ibm.com/docs/en/ibm-mq/9.1?topic=arc-2031-07ef-rc2031-mqrc-msg-too-big-q-mgr)
I changed the maxmsgl value for the Queue manager and the SVR channel as well. I ran the following commands for this:
runmqsc QM1
ALTER QMGR MAXMSGL(104857600)
ALTER CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) maxmsgl(104857600)
But still the error persists, could someone reflect on what needs to be done regarding this error code. And also as message segmentation is not allowed on pubsub what is the maximum limit of message size it can handle.
When using a topic for publish/subscribe, the messages sent to subscribers are still put onto a queue for safe storage until they are consumed by the subscribing/getting application. These queues must also have MAXMSGL set appropriately.
If you do not know which queue to adjust, follow these steps:-
Run the subscriber application - assuming that it will wait around for a while
Issue the following MQSC command (e.g. using runmqsc):-
DISPLAY SUB(*) DEST DESTCLAS TOPICSTR DURABLE
The name shown in the DEST field in the output is the queue your subscription is using. If it's name starts with SYSTEM.MANAGED and it also shows DESTCLAS(MANAGED) then your subscription is a managed subscription. You say that your subscription is not managed, but if you don't know which queue is in use by that subscriber then it is most likely that it IS managed, since that means you don't have to worry about the queue.
A managed subscription queue is built from a MODEL queue referenced on the topic. If you are unsure which MODEL queue would be used, issue the following command using the TOPICSTR value from the output of the above command.
DISPLAY TPSTATUS('topic-str-value') MNDURMDL MDURMDL
If the output from the DISPLAY SUB command earlier showed that your subscription was DURABLE(YES) then the MODEL queue in use is the one shown in the field MDURMDL (Managed DURable MoDeL). If it showed DURABLE(NO) then the MODEL queue in use is the one shown in the field MNDURMDL (Managed Non-DURable MoDeL).
Using the name determined in step 4 if it is not managed, or in step 5 if it is managed, issue the following MQSC command:-
ALTER QLOCAL('q-name-from-step-4') MAXMSGL(104857600)
or
ALTER QMODEL('q-name-from-step-5') MAXMSGL(104857600)
Now re-make your subscription (so that it deletes the previous temporary queue it created and makes a new one from the model) and re-run your publisher application.
I'm working on an node js application, called ngdf-diversion-client, that is running in AWS and is connecting to a Solace instance, that is also running in AWS.
I see that through the ngdf-diversion-client config file its receiving messages over the ngdf/diversions queue, and I can see that in the SolAdmin.
This image here shows the application ngdf-diversion-client listed in the SolAdmin tool:
This image shows ngdf-diversion-client being the owner (and in my case the recipient of data) on the ngdf/diversions queue:
But I cannot see who sends data to ngdf-diversion-client on the ngdf/diversions queue.
Does anyone know how I can see that information in Solace or SolAdmin?
I know with ActiveMQ when you select a Queue or Topic from the web console, you can see who are the consumers and producers so it was pretty easy seeing who sent and who received data over a queue or topic.
But with Solace/SolAdmin I don't see that.
With Solace, publishers and subscribers are decoupled by design so there is no way to see which publishers have sent messages to a specific queue. If it is required that the publisher of a message is identifiable then you could implement an identifier in the message as it is published in the application.
As a part of data integration between two application, we plan to send data to Azure service bus queue. On the receiving end I've an API that loads the data to target DB.
I need to understand how can I handle the following:
1. How should the API be notified whenever the messages arrives in the queue. I am thinking of Azure function or web job or some scheduling component.
2. What if an API is down, messages should retain in queue.
3. What if when API receives the message but somehow the target DB is down. In that case, my messages should be retained in the queue for retries.
Please help me and guide me to get the correct approach to implement this.
Thanks!
Logic Apps! Use Logic Apps with Service Bus Queue Trigger so that it fires on the arrival of new messages in Service Bus Queue. To send the data to Web API, use Logic Apps Http Connector.
It is scalable by individual messages.
How should the API be notified whenever the messages arrives in the queue. I am thinking of Azure function or web job or some scheduling component. Logic Apps
What if an API is down, messages should retain in queue. Azure Service Bus Queue ensures FIFO, Batching,.. Messages are retained until it is de-queued and deleted
What if when API receives the message but somehow the target DB is down. In that case, my messages should be retained in the queue for retries. Check transaction feature of Azure Service Bus Queue
I am looking for a way for each consumer instance to receive a message that is published to RabbitMQ via MassTransit. The scenario would be, we have multiple microservices that need to invalidate a cache on notification. Pub-Sub won't work in this instance as there will be 5 consumers of the same type as its the same code per service instance, so only one would receive the message in a traditional PubSub.
Message observation could be an option but this means the messages would never be consumed and hang around forever on the bus.
Can anyone suggest a pattern to use in the context of MassTransit?
Thanks in advance.
You should create a management endpoint in each service, which could even be a temporary queue (just request a receive endpoint without a queue name and one will be dynamically generated). Then, put your queue invalidation consumers on that endpoint. Each service instance will receive a unique instance of the message (when Publish is called), and those queues and bindings will automatically be removed once the service exits.
This is exactly how the bus endpoint works, but in your case, you're creating a receive endpoint which can have consumer message type bindings, so that published messages are received, one copy per service.
cfg.ReceiveEndpoint(cfg => { ... });
Note that the queue name is not specified, and will be automatically generated uniquely.
I want to know how do I retrieve the messages already present on the Solace Queue. I am able to send and receive the messages I created from my machine but can't receive any messages that are already present in the queue. I want to retrieve the messages and store it in a text file.
I am sending my messages by integrating Solace APIs in Gradle and writing code in Java. Can anyone guide me regarding the same?
There's an exact tutorial for this.
If you had downloaded the Solace Java JAR via the Maven links, you might have missed the entire suite, which contains all the dependent JARs distributed by Solace, API reference docs, as well as a bunch of samples. The latter is in addition to what you may find on http://dev.solace.com/get-started/java-tutorials/. Get the entire ZIP file, as well as the Release Notes, from http://dev.solace.com/downloads/.
There are multiple possibilities why you cannot receive messages from a queue:
Queue name is misspelt.
Queue permissions are wrong.
Queue is shut down on the egress.
Message spool is not active on the router.
Client profile is set not to receive Guaranteed Messages.
Number of egress flows has exceeded the router / message-vpn limit.
Bind count on the queue has exceeded.
The egress flow is not active.
Client is not connected to the router.
...
Examining the error / exception will give you information why you cannot receive messages.