1

The documentation on BrokeredMessage says:

If the TTL set on a message by the sender exceeds the destination's TTL, then the message's TTL will be overwritten by the later value. See DefaultMessageTimeToLive, DefaultMessageTimeToLive and DefaultMessageTimeToLive to learn more about how to control message TTL at an entity level.

So, to achieve messages to be automatically removed from my "Log" subscription, When creating the subscription, I have set the SubscriptionDescription.DefaultMessageTimeToLive property to TimeSpan.FromDays(5).

When I create and send a brokered message, leaving the TimeToLive property on that message to the default value, when I inspect messages arriving in that the subscription, the ExpiresAtUtc property for the messages is 31-12-9999 23:59. and the TimetoLive property is 10675199.02:48:05.4775807. Since the TTL on the 'destination' subscription is 5 days, I would have expected a value 5.00:00:00 there.

Is there something else that I need to do to get this working?

Steps to reproduce with Service Bus Explorer 2.2.1.0

  1. Connect to a Service Bus Namespace on azure
  2. Create a new topic "MyTopic"
  3. Create a subscription "Log" under the topic and set the Default Message Time to Live to 5 days.
  4. Right click on the MyTopic topic node and choose "Send messages"
  5. On the "Send messages to MyTopic" screen: click "Start"
  6. Click the "Log" subscription node
  7. Click the "Messages" button and choose Peek 10
  8. Click the message in the list
  9. Look at the TimeToLive field in the "Message Properties" area
veertien
  • 457
  • 5
  • 18
  • you may use this tool to verify if the TTL you set on subscription has really been applied or some other issue http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a – Dhana Krishnasamy Dec 16 '13 at 15:41
  • @DhanaKrishnasamy: I'm allready using that tool. It shows the subscription has "Default Message Time To Live" is set to 5 days. It also shows that the messages in that subscription (using Peek) all have "TimeToLive" set to 10675199.02:48:05.4775807 – veertien Dec 16 '13 at 16:14
  • posting the code and screenshot might help you answer quickly – Dhana Krishnasamy Dec 16 '13 at 16:21
  • I have added "Steps to reproduce with Service Bus Explorer 2.2.1.0" to my question. Hope that that clarifies the situation. – veertien Dec 16 '13 at 16:39
  • I have ttl as 5 when i received the message – Dhana Krishnasamy Dec 16 '13 at 17:03
  • @DhanaKrishnasamy: I also get 5 days when I follow my own reproduction steps and use "Receive" for receive mode in step 7. What I did earlier was to use "Peek" for receive mode. When using "peek", the TimeToLive on the message shows `10675199.02:48:05.4775807` when using "receive" the message shows `5.00:00:00` – veertien Dec 17 '13 at 08:33
  • Though Peek is only for browsing the message and you need Receive to get the message ,which will give the correct TTL, wrong TTL in Peek seems to be bug as one might want to just check the TTLs of the message by Peeking. You may raise this in MSDN blog as well. – Dhana Krishnasamy Dec 17 '13 at 10:03

3 Answers3

4

Apparenlty the TTL value on peeked messages is meaningless:

This behavior is currently by design and should be seen independent of SDK version: the effective TTL is the minimum TTL of message and entity and is checked at runtime, rather than imprinted on the message at enqueue time (because the entity-level TTL could be changed at any time after messages were enqueued). The documentation is misleading and should be fixed.

This answer was given on this MSDN thread: http://social.msdn.microsoft.com/Forums/windowsazure/en-US/dfe58dbb-186d-4c71-a708-8f6f7267b451/when-peeking-for-messages-the-time-to-live-value-seems-not-to-be-set-is-this-a-bug

veertien
  • 457
  • 5
  • 18
0

You have to set the DefaultMessageTimeToLive property when you create the queue itself and not when you create the queue client. Try deleting the queue and creating it again with the new queue description.

Bitsian
  • 2,238
  • 5
  • 37
  • 72
  • 1
    What you descibe is what I allready did. I set the `SubscriptionDescription.DefaultMessageTimeToLive` value and then created the subcscription. I see my setting reflected when I use Service Bus Explorer to view the subscription details. I just doesn't get applied. – veertien Dec 16 '13 at 16:09
0

You need to log into your topic and set “Default Message Time to Live” to 14 days.

What went wrong? Luckily this error was self-explanatory and indicating that the Max Topic size is 1 GB (1073741824 bytes) while the Topic is already utilized 1073742326 bytes which translates to approx 1 GB limit. We logged into the Azure Portal and verified the same. Next we ran Service Bus Explorer to check the status of the messages. We saw thousands of messages are in the Topics.

Why messages were not getting cleared from the Topic? Now the obvious question arise, what is keeping those thousands of message in topic. After some investigation we found that “Default Message Time to Live” for Topic was set to very high number. In this case it was set to 1 year. In order to fix the issue, we set “Default Message Time to Live” to 2 days as recommended by the their App Developer. This resolved the issue. Here is a screen-shot of the configuration from Azure Management Portal:

See: https://blogs.msdn.microsoft.com/cie/2013/07/21/service-bus-error-the-maximum-entity-size-has-been-reached-or-exceeded-for-topic/

Ravit D
  • 907
  • 9
  • 27