0

I noticed that the message's EnqueueTimeUtc value is not accurate

I am using ServiceBus Topics and Subscribers for my system

The Sender side is written in .NET using "Microsoft.Azure.ServiceBus" Version="4.1.1" NuGet package Using the SendAsync() method to send messages to topic

The Subscriber side is written in Python using azure.servicebus.control_client (azure-servicebus version 0.50.3) Using the receive_subscription_message() method with peek_lock=True to receive messages

When I received the message on the subscriber side, I exported the 'EnqueuedTimeUtc' property from the received message and it's value was 'Tue, 21 Jul 2020 08:41:37 GMT'. But, I noticed that the time was not accurate (it was ~7 seconds later than current time) On the sender side, I added a log AFTER the message was sent and the timestamp of the log was '7/21/2020 08:41:29.5047754'

Both sender and subscriber were running on my local machine and the ServiceBus location is 'West US'

Am I missing something?

Yoni Adir
  • 3
  • 1

1 Answers1

0

The one subtlety that may be missing here is that EnqueuedTimeUTC is set by the service, not the sender. Thus, both the sender and receiver clocks may be distinct (both from the service, and if they are on different machines, from each other) and as such I would not be surprised to observe limited skew as you've noted.

Full disclosure, am one of the maintainers for the Python SB SDK, so feel free to let me know if more clarification is needed or if I've missed something; I hope this has been helpful!

Kibrantn
  • 609
  • 3
  • 4
  • I will explain my problem in more detail. I try to measure how long it takes to dequeue a message from a service-bus topic. The subscriber code is written in Python and I am using the receive_subscription_message() method with peek_lock=True to receive messages. The receive_subscription_message() method waits X seconds for a new message, and dequeues it when a message appears in the topic. Since the receive_subscription_message() method waits for a new message to appear in the topic, I can't really know how long does it take only to dequeue a message – Yoni Adir Aug 04 '20 at 21:08
  • Fundamentally the problem as I tried to call out earlier, is that you don't know the clock skew between yourself and the datacenter clock, which sets EnqueuedTimeUTC. By supplementing the logs you mentioned earlier you can likely come up with a first-order approximation of send and receive latencies, but it would be best-effort only. – Kibrantn Aug 06 '20 at 22:59
  • Thanks for your answer. I will think of another approach to solve my problem – Yoni Adir Aug 10 '20 at 07:43