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

Network calls stop when API interface uses HttpResponseMessage result types #332

Closed
gentilim opened this issue Jun 29, 2017 · 3 comments
Closed

Comments

@gentilim
Copy link

When creating a Refit API interface that returns a Task for all method calls appears to break. The exception shows that "A task was canceled." which I interpret as a timeout error. When I use Fiddler to monitor the network traffic, the call that resulted in the error never actually makes an external call, so it does not appear to be an issue with the remote API or handling the result, but rather Refit making the API call.

Here is a Gist that has two tests to demonstrate the issue; one uses the Refit API interface that returns model results (TestCreates - passes), and the other uses the Refit API interface that returns HttpResponseMessage results (TestPosts - fails).

Gist tests: https://gist.github.com/gentilim/8845600c874624f771eff75cb37487c3

I've noticed that the last failing call can occur on either a DELETE or POST (consistently), and haven't seen it fail on any GET (consistently).

More testing/information can be provided as needed.

@mfelicio
Copy link

I'm surprised nobody replied to this yet since it's been nearly two years since you've opened the issue. I just had the exact same problem and found the root cause, as well as a solution.

The problem is that by exposing the HttpResponseMessage, Refit won't dispose of the response's Content stream, therefore leaving the underlying tcp connection still active. Now, there's a limit to how many concurrent connections you can make per host (configurable via ServicePointManager), In my case it was a console app and the default is '2', so when making the third request it would just hang. Basically the request is queued on the client side, waiting for a tcp connection to be freed or to establish a new one.

There's a few solutions/workarounds to this problem, but the solution I ended up going with was to expose your response via the ApiResponse wrapper provided by Refit. This will internally read the stream and dispose of it, so freeing the underlying connection.

Cheers!

@clairernovotny
Copy link
Member

Closing due to age. Please try Refit v6 and reopen if still an issue.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants