DZone
Performance Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Performance Zone > The Case of the Hanging Request in the Cache

The Case of the Hanging Request in the Cache

A user of RavenDB reported that all requests were hanging and eventually timed out. We were able to fix the problem... but we still don't know how to reproduce it.

Oren Eini user avatar by
Oren Eini
·
Jun. 15, 17 · Performance Zone · Opinion
Like (1)
Save
Tweet
2.27K Views

Join the DZone community and get the full member experience.

Join For Free

A user just reported that after a short time of using RavenDB, all requests started to hang and eventually timed out. We are talking about making several dozen requests in the space of a minute or so, as a user operating against a web application.

That was a cause of concern, obviously, and something that was very strange. Luckily, the user was able to send us a stripped down version of his application and we were able to reproduce this state locally — on that particular application only. We couldn’t reproduce this anywhere else.

In fact, we fixed the problem and still don’t know how to reproduce it. The underlying issue is that we are making a GET request using HttpClient and specifying HttpCompletionOption.ResponseHeadersRead  in the SendAsync method. Now, the server might return us a 304 response, in which case we’ll use the cached value we have. If we make a few requests like that, all future requests will hang. In order to fix this problem, we need to dispose the response or read the (empty) content of the response.

Now, the crazy thing is that I can probably speculate pretty accurately on why this is going on — we have fixed it — but I can’t reproduce this problem except within the application the user sent us. So, no independent reproduction.

The likely issue is that the HttpClient considers the request open until we read all its content (even if there is none), and that as we make more requests that have the same 304 and therefore there's no access to the content of the request, we have more and more requests that are considered to be open, up to the maximum number of requests that are allowed against the server concurrently. At this point, we are waiting for time-out, and it looks like we are hanging.

All very reasonable and perfectly understandable (if only annoying because if you only need to dispose of it, sometimes is a trap waiting to happen), but I don’t know why we couldn’t reproduce it.

Requests Cache (computing)

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Path-Based Routing in Render With Kong API Gateway
  • How to Start Using Natural Language Processing With PyTorch
  • Templates Are Indispensable for GitOps-Driven Automation
  • Flutter vs React Native. How to Cover All Mobile Platforms in 2022 With No Hassle

Comments

Performance Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo