Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Deadlock prone code in HttpConnection.cs #689

Open
DavidPoulsenHGS opened this issue Jul 2, 2024 · 4 comments
Open

[BUG] Deadlock prone code in HttpConnection.cs #689

DavidPoulsenHGS opened this issue Jul 2, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@DavidPoulsenHGS
Copy link

What is the bug?

The HttpConnection class contains the following code in the Request method:
responseMessage = client.SendAsync(requestMessage, HttpCompletionOption.ResponseHeadersRead).GetAwaiter().GetResult();
and a little further into the same method:
responseStream = responseMessage.Content.ReadAsStreamAsync().GetAwaiter().GetResult();

These two lines of code are prone to deadlocks due to calling GetAwaiter().GetResult(). This link explains why.

A surprisingly similar issue has been discussed to great length in an ElasticSearch.Net issue as well.

How can one reproduce the bug?

It's difficult to reproduce. Essentially requires continuously calling the Request method from multiple threads to provoke a deadlock. It can be quite common under load in a production environment, however.

What is the expected behavior?

The code should be free of potential deadlocks. I suggest changing the implementation to use the synchronous "Send" method of the System.Net.HttpClient instead.

@DavidPoulsenHGS DavidPoulsenHGS added bug Something isn't working untriaged labels Jul 2, 2024
@Xtansia Xtansia removed the untriaged label Jul 3, 2024
@Xtansia
Copy link
Collaborator

Xtansia commented Jul 3, 2024

Hey @DavidPoulsenHGS,

Thanks for reporting this, this is definitely something we'd want to address. I think the currently in-dev next major version would provide a good opportunity to handle this and add the additional target framework for .NET 6.0+.

Is this something you'd be potentially interested in looking into and contributing? No pressure if not!

@DavidPoulsenHGS
Copy link
Author

Perhaps, depending on the complexity. I'd like to give it a shot, at least.

How would I go about doing this? Do I just fork the 1.x branch and submit a pull request?

@Xtansia
Copy link
Collaborator

Xtansia commented Jul 3, 2024

@DavidPoulsenHGS All changes should generally go into the main branch (and then potentially backported to 1.x). So you'd fork the repository, branch off of main, make your changes and then raise a pull request.

Even partial solutions can be helpful, so if you do feel stuck you can always raise a draft pull request and I can help give feedback or try to guide things in the right direction.

DavidPoulsenHGS added a commit to DavidPoulsenHGS/opensearch-net that referenced this issue Aug 1, 2024
@DavidPoulsenHGS
Copy link
Author

I have made a pull request for my fix now: #737

The unit tests fail on my machine on a clean checkout (without my fix), so it's quite difficult for me to test that my change works. It is a very simple fix - perhaps someone else can run the unit tests on it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants