I have recently started working on Azure Service Bus module which is currently used in our project. The current model is that, we send message to a topic and the topic has multiple subscriptions. There is no filter for subscriptions and the subscribers consume it(Currently not looking to add filters).
Question: Let's say there is 1 topic and 3 subscriptions. The message sent to topic is broadcasted to all subscriptions and applications from two subscriptions consume it. Application for the third subscription goes down and the message is not consumed.
What happens to the message from the 3rd subscription, will it be sent to Dead Letter Queue after TTL
Is there a way to find out, for which subscription the message wasn't consumed
What happens to the message from the 3rd subscription, will it be sent to Dead Letter Queue after TTL
If subscription is configured to dead-letter expired messages, yes, that's what will happen.
Is there a way to find out, for which subscription the message wasn't consumed
You shouldn't do that. Topics and subscriptions are intended to implement Pub/Sub pattern and is about decoupling the senders from the receivers.
Related
As a MQTT client I want to know how can I get subscriptions(TOPICS):
I use Paho library and java as a client, with connecting with setCleanSession(false) so the client subscriptions(TOPIC) keeps in MQTT broker after disconnecting, if the topic subscription didn't emits some data , I didn't know that subscription is alive.
so I want to get all topic subscriptions of my MQTT client and if some topic didn't emits data for 10 minutes , unsubscribe that topic.
You can not.
There is no way to query the broker for what topics the client has subscribed to in the protocol and in fact most MQTT client libraries don't even keep a list of subscribed topics for the current session.
We have a producer service which is publishing a message to topic and we have 3 instances of consumers reading that message from topic. Producer needs to do further processing (update DB) only when all consumers processed and replied a success message in another reply queue. Even if one of the consumer service failed due to some exception or any failure message in reply queue, producer should not do update DB for that publish request.
For next request (new message published in topic), if all consumers processed and replied in reply queue, producer should update DB. How can we achieve this with camel and activemq. Is there any EIP pattern(s) to achieve this?
Any
Yes, the producer can just use the aggregator enterprise integration pattern on the reply queue to ensure all 3 consumers processed the previous message.
Doc: Apache Camel aggregator2 component.
You will need a unique key and use a proper aggregation strategy.
If I understand JMS correctly, the consumer sends acknowledgement to the broker, and the broker understands that the consumer accepted the message. But how does the producer make sure that broker accepted the message? I don't see any acknowledgements in the API.
Does the method send sync or async?
Acknowledgement is a consumer side concept. Acknowledgement is the way
that a consumer informs the JMS provider that it has successfully
received a message. On the producer side, the only notion of
acknowledgement consists of a successful invocation of either the
topic publishe’s publish method or the queue sender’s send method. If
an acknowledgement is given for a message it indicates that the JMS
provider must not deliver that same message to the consumer in
question again and also the JMS provider can release any resources it
is holding on behalf of the said message (i.e if a JMS queue is
considered after acknowledgement of successful delivery, that message
is removed from the queue). In order to minimize resource consumption,
consumer applications need to acknowledge messages as quickly as
possible after successful delivery.
source: http://wso2.com/library/articles/2013/01/jms-message-delivery-reliability-acknowledgement-patterns/
During configuration of JMS queues on JBoss 7 with HornetQ (based on standalone-full.xml configuration) I noticed an attribute 'durable'.
I browsed several sources and many of them stated queues are always 'durable', meaning the message will be always delivered, even in case of potential receivers being inactive at the time of send.
Does this attribute in JBoss 7 HornetQ refer to temporary queues? Or does this attribute refer to some kind of non-temporary non-durable queues?
I feel the word "Durable" is more applicable to Topics than queues. A durable subscription is one where the publications for a subscriber are stored by the messaging provider when that subscriber is not running. Once the subscriber becomes active, these stored messages will be delivered to that subscriber. For non-Durable subscribers will not receive any publications if they are not active.
With respect to Queues, the messages are held in the queue till someone receives them or they expire. The messages can be persistent meaning they will survive restart of messaging provider and non-persistent where the messages are lost when messaging provider goes down.
After brief investigation I came up with a few conclusions. All observations are based on JBoss 7.1.1.Final with HornetQ Server 2.2.13.Final.
The non-durable queue is not a temporary queue. It exists until it's manually deleted.
All the messages submitted to non-durable queue vanish upon JMS provider restart/failure (delivery modes, i.e. PERSISTENT / NON_PERSISTENT of the submitted messages are ignored).
The value of JMSDeliveryMode header element of the messages is not modified. In particular, if the message was submitted with PERSISTENT delivery mode to a non-durable queue, the flag is set to PERSISTENT, even though the non-durable queue does not persist the message (it is lost in case of JMS provider restart/failure).
From the client side it seems to be a bit of a disturbing prospect, since the sender has potentially no way of knowing whether the declared delivery mode of the message will not be respected, due to the problematic meaning of 'non-durable' queue.
Furthermore, the term 'durable queue' in this context seems disjointed from the 'durable subscription', as it does not appear to affect delivery of messages to inactive consumers in any way.
Durable subscription in JMS means that if subscriber disconnected and then connected again to JMS destination (queue or topic) it will receive all messages that have been sent to the destination so far and have not been expired yet.
I am using seda queue as dead letter channel endpoint. It works fine if network is down or other application is down.
What will happen if I restart my own system?
Will I loose my messages in dead letter channel endpoint SEDA queue?
The seda endpoint is not a reliable message solution, meaning any messages sent to a seda destination are subject to loss in the event of a failure/restart. If JMS is not an available solution you will need to provide your own persistence logic to provide message recovery.
Additionally, given that seda endpoints are asynchronous, you must ensure that a pattern of message acknowledgement is used post persistence of the DLQ message so your producer to the DLQ will be notified of success or failure to ensure reliability.
This of course when using a DLQ. You could also use a persistence preprocessor that would store messages meant for delivery and only delete them in the case of a failure to deliver them.