0

When inspecting incoming requests in e.g. a PreRequest event handler in Global.asax.cs, I see that HttpContext.Current.Timestamp for a request is sometimes earlier than a previous request. Why is that?

It also looks like the order is random in my experiments, meaning that sometimes one request comes before another, and sometimes the other way around.

The documentation for HttpContext.Timestamp says "The timestamp returned from the Timestamp property is the local time of the server and is set during the instantiation of the HttpContext object." And, HttpContext.Current is "the context for the current request".

If HttpContext is created by ASP.NET, and HttpContext.Timestamp is the time of creation, why aren't I seeing the requests in a strict chronological order? What am I missing?

My application is using ASP.NET MVC 5 (with sessions). The requests are a mix of Razor views, server-rendered images and scripts and AJAX calls for data.

Christian Davén
  • 16,713
  • 12
  • 64
  • 77
  • Because somewhere in between instantiating the `HttpContext` and calling your PreRequest event handler (`Application_BeginRequest`?), the OS determined that the CPU had something more important to do, I guess? What is your actual question, is order important for your application? – CodeCaster Jul 01 '20 at 09:12
  • @CodeCaster, Yes, this caused a bug in my application, when a request with an "old" cookie got processed after a "new" cookie. I'm also curious, since ASP.NET uses a session lock to prevent requests from processing simultaneously, which should make things a bit more deterministic? See https://stackoverflow.com/q/3629709/12534 – Christian Davén Jul 01 '20 at 09:39
  • If I interpret that right, the response to request 1 has a set-cookie header that request 2 should use. Then the caller should wait for the response on the first request before issuing a new one. – CodeCaster Jul 01 '20 at 09:40
  • If you issue interdependent requests semi-simultaneously, you'll have a race condition by design. Each request could take a different network route, affecting transit times. Each request could end up on a different thread or CPU on the server, and you can't control which request gets prioritized i.e. processed first, and even then, the ASP.NET runtime may initialize two HttpContexts around the same time for two different requests, and only after that, try to acquire the session lock. First one there wins, you can't control this. – CodeCaster Jul 01 '20 at 09:44
  • @CodeCaster I have already solved my bug, but I want to understand what is happening, to avoid other bugs. That's why I didn't explain more about what was happening in my particular case. – Christian Davén Jul 01 '20 at 09:45
  • If you want to know why this happens, then that's the answer: between the HttpContext instantiation by the runtime, locking, loading and assigning the session object and finally instantiating your controller and passing it the request, the CPU has executed millions of cycles and the OS may have switched the CPU to a different thread. This is why one request takes longer to process than the other, and you might see them arrive in a different order than they were issued. In layman's terms, of course, you'll have to dive deep into the docs (and perhaps source) to get an official explanation. – CodeCaster Jul 01 '20 at 09:47
  • @CodeCaster But isn't `HttpContext.Timestamp` set exactly when the `HttpContext` is initialized? So everything before that is irrelevant. Why does ASP.NET initialize two requests in one order, but let me process them in a different order? – Christian Davén Jul 01 '20 at 09:47
  • Yes, but between initializing the `HttpContext` and raising the `Application_BeginRequest` event, a lot has happened on the background. The time this takes can vary. – CodeCaster Jul 01 '20 at 09:48

0 Answers0