Is there Azure service bus message expire event? .
I could see TimeToLive property according this source. i am sending messages to azure service bus queue and need to identify when those message are expired .
Expired messages are dropped from the queue. There's no event.
You can enable dead-lettering of the expired messages and the dead-letter reason would indicate message expiration as the reason for the message ending up in the dead-letter queue.
Related
I’m using Masstransit request/response pattern. So I’ve a requester application and a consumer application, which is working very well. I didn’t configure any retry/redelivery as if there is any error happen into consumer , the requester will handle it or might be send another request. So far so good.
But if the consumer application crash and restart in the middle of the process , the consumer try to take the message from queue and start reprocessing it, which is not intended for my case. Because the requester will get error response (or timeout) when the consumer application crashed. I know that MessageRetry in MassTransit is entirely in-memory.
My question is, can we somehow stop consumer to reprocess message on application restart ? OR we need to remove the pending message from service bus queues?
There is no connection between a message sent by the request client and the request client. Using the request timeout as the default value, MassTransit sets the TimeToLive of the message to that same value. The transport should remove that message once the TimeToLive has expired.
If the consumer application crashes consuming a message, that message will remain on the queue. If that message repeatedly causes your application to crash, you could check the Redelivered property that is on the ReceiveContext (a property on ConsumeContext) and possibly handle that message another way if you believe the message is causing the process to crash.
Of course, the real solution is to fix the consumer so it doesn't crash the process...
UPDATE
You could configure the receive endpoint with a DeliveryCount of 1 if you want Azure Service Bus to move the message to the dead-letter queue if the consuming process crashes.
I have an issue related to java messaging service ...
Problem: suppose my JMS publisher sends me 5 messages... When I receive first two messages my app processes them and acknowledges them... So that it is removed from the topic... Wen I receive 3rd message, because of some problem my app cannot process it and doesn't acknowledge... But 4th and 5th message got processed and acknowledged... But wen I checked the admin console I found out that the 3rd message is also acknowledged...
I want to know how to acknowledge each message individually. Anybody has idea???
Note: I'm using CLIENT_ACKNOWLEDGE mode.
According to JMS specification CLIENT_ACKNOWLEDGE - acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session.
Many JMS providers have implemented above specification and hence don't provide acknowledging one message. But some JMS providers (AcitveMQ ??) do implement per message acknowledgement. So you will need to check with your JMS provider if it supports per message acknowledgement feature.
Is there any way we can know when a consumer disconnects from a queue or when a queue is deleted?
The requirement is as follows:
I'm building a system in which multiple clients can subscribe to certain events from the system. All clients create their own queue and registers themselves with the system using some sort of authentication. The system, as the events are generated, filters the events and forwards them to clients who are eligible for them.
I have implemented a POC for most part of it and it works well. An issue that I'm not able to fix is that, if a client just disconnects from the queue (due to program termination or so), the registration still exists and the system keeps trying to push messages to that client.
So we would like to be notified when a client disconnects or a queue gets deleted so that we can remove that client's registration data and no longer push messages to him.
Let your publisher utilize Confirms (aka Publisher Acknowledgements) and make client queue be exclusive and transient, so only one client at a time will be consuming from one queue and after it disconnection it will be deleted.
If you publish message that get routed to only one queue and that queue gone (assume you utilize publisher confirms and publish message with mandatory flag set) publisher will be notified that message cannot be routed with that message returned back to it, so you can stop publishing messages.
For details see How Confirms Work section in RabbitMQ blog post "Introducing Publisher Confirms" and Confirms (aka Publisher Acknowledgements) official docs.
Spring Message Listener Container doc says:
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/listener/AbstractMessageListenerContainer.html#setDurableSubscriptionName%28java.lang.String%29
The durable subscription name needs to be unique within this client's
JMS client id. Default is the class name of the specified message
listener. Note: Only 1 concurrent consumer (which is the default of
this message listener container) is allowed for each durable
subscription.
I thought, we can handle concurrent messages at the same time. Am I missing something?
Yes, the documentation is correct. At any point of time there can be only one consumer receiving messages for a durable subscription. All durable subscriptions are identified by a unique id. If one consumer is already receiving messages using an id, another attempt create a consumer with the same id for that durable subscription will fail.
I've had this problem before and our log was full of warnings complain about client id is already in use.
Virtual Topic is an option for ActiveMQ: the idea is similar to what #brainOverflow described, it's a combination of topic and queues. The producer sends the message to a topic which is subscribed by queues and each queue receives a copy of the message.
http://activemq.apache.org/virtual-destinations.html
I am using ActiveMQ as a JMS implementation server in my application. Scenario is like, there is a topic over which I have many durable subscribers which consumes the published message and a message listener which save the data from message object to central DB server. There is a producer thread which keeps on publishing persistent message over the same topic. I am using KahaDB for persistent Message Store. As soon as a message is published, kahaDB creates a data log file in message store to persist message until all durable subscriber consume it. I want to know if at any point, I shutdown the JMS server and delete all the data log files, what would be the impact. Will it be just that few durable subscriers will not receive a message which was there in data log files for them to be consumed or is there a possibility that few message didn't got saved in central database which is done by message listener over this topic.
Any hint or help is greatly appreciated......
Thanks in advance.
If you stop and start your broker, regardless of whether you delete your data files or not, topic consumer that have not already received a published message will no longer receive it. The reason behind this is that messages sent to a topic will not be written out to the persistent message store.
Durability and persistence are not the same things. A durable subscription tells the broker to preserve the subscription state in case the subscriber disconnects - any messages sent while the consumer is disconnected will be kept around. A non-durable subscription on the other hand is finite; if a subscriber disconnects, it missed any messages sent in the interim. All messages are stored in memory, and will not survive a broker restart.
Message persistence on the other hand stores messages for eventual delivery. This guards against catastrophic failure, or for later delivery to consumers who might not yet be active.
If you want to broadcast messages using pub-sub, and have the subscriptions appear durable and survive broker restarts you should use virtual destinations instead of durable subscriptions.
No messages, persistent or non-persistent, will survive switching the broker off and deleting the data directory.