6

I am trying to create azure service bus queue using azure-sdk-for-node but not able to find the resource to set time to live unlimited .

Here is my sample code :

var queueOptions = {
      MaxSizeInMegabytes: '5120',
      DefaultMessageTimeToLive: 'PT1M'
    };

serviceBusService.createQueueIfNotExists('myqueue', queueOptions, function(error){
    if(!error){
        // Queue exists
    }
});

What will be in DefaultMessageTimeToLive for unlimited time ?

0xsegfault
  • 2,899
  • 6
  • 28
  • 58
AvinashSachdewani
  • 146
  • 1
  • 8

2 Answers2

10

Your code sets the message TTL to 1 minute only. You can't set TTL to unlimited as it requires a TimeSpan value, so you have to assign something. It could be a fairly large value, but I'd recommend to avoid this practice for a few reasons:

  1. It's a hosted service. TTL is not constrained today, but could be.
  2. For messaging, having a very long TTL is an indication of something that should not be done (messages should be small and processed fast).

Saying that, as of today, you could set TTL to the TimeSpan.MaxValue, which is

  • 10675199 days
  • 2 hours
  • 48 minutes
  • 5 seconds
  • 477 milliseconds

or in iso8601 format is P10675199DT2H48M5.4775807S.

Realistically, 365 days (P365D) or even 30 days (P30D) is way too much for messaging.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Thanks for the response Sean. But according to this comparison (https://azure.microsoft.com/en-in/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted/) it's a feature of service bus queue. – AvinashSachdewani Jul 27 '16 at 13:29
  • Well, documentation is written by humans.10675199 days is roughly 29247 years. I'm sure for an application you're creating it could be easily considered unlimited :) The point I'm trying to convey, beyond how to get a super big TTL, is that you shouldn't be accounting on that to be supported in the future. Messaging should be fast, having to store your messages that long is more of an exception than a rule. – Sean Feldman Jul 27 '16 at 13:32
  • Also, try going beyond TimeSpan.Max by a millisecond, and ASB will reject that TTL value. So, TimeSpan.Max is the unlimited. I've opened a PR to clarify that here https://github.com/Azure/azure-content/pull/7117 – Sean Feldman Jul 27 '16 at 13:40
  • thanks for the PR Sean :) Yes I understand the point you mentioned . – AvinashSachdewani Jul 27 '16 at 13:45
  • I would just like to resound Sean's premise that messages should be small and processed fast. Anything over 30 days.......is a red flag. – granadaCoder Sep 12 '16 at 14:38
  • In general, messages are short lived. However, it's very reasonable that one could last for days or even months. Examples are, processing an order that can't be done due to an outage (good use of messaging), the outage could last a day or two, then when its fixed those orders will be processed. You may want to delay the message being processed, now granted this is a slightly different feature ie scheduling, but the message still has to exist. Example, renew customer subscription in 12mths. – dnp Aug 23 '18 at 19:16
0

"The default time-to-live value for a brokered message is the largest possible value for a signed 64-bit integer if not otherwise specified." (From Microsoft docs)

Sagi Sulimani
  • 66
  • 7