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

Singleton refit does not send all parallel requests #449

Closed
alextrukhan opened this issue Mar 3, 2018 · 9 comments
Closed

Singleton refit does not send all parallel requests #449

alextrukhan opened this issue Mar 3, 2018 · 9 comments
Labels

Comments

@alextrukhan
Copy link

Singleton refit does not send all parallel requests, only part of requests were sent. Run example project to see issue. RunRefit method creates new instance of refit api for each request. RunRefitStatic uses static instance of refit api and static HttpClient. RunRefitWithSingleHttpClient uses static HttpClient and new instances of refit api for each request.
RunRefit works well but RunRefitStatic and RunRefitWithSingleHttpClient do not work as expected.

RunRefitStatic and RunRefitWithSingleHttpClient does only 2 request unlike RunRefit. When I use static HttpClient for parallel request everything is good.
Could I use singleton refit api or refit api with singleton HttpClient?

@bennor
Copy link
Contributor

bennor commented Mar 13, 2018

Seems like a deadlocking issue. In theory you should be using a singleton HttpClient, and I've always done that myself in the past. It shouldn't matter whether you use a singleton Refit instance or a new one each time.

I've never noticed a problem so this could be a regression (or perhaps I never issued simultaneous requests).

@bennor bennor added the bug label Mar 13, 2018
@robichaud
Copy link

@bennor have you had an opportunity to look into this? I believe I am running into the same issue.

@bugproof
Copy link

bugproof commented Aug 6, 2018

Encountered the same issue.

@bugproof
Copy link

bugproof commented Jul 19, 2019

EDIT: it looks like it's not a bug. The example is not disposing HttpResponseMessage and that's why it's deadlocking. See referenced issue. Also, see aspnet/Security#886

@bennor
Copy link
Contributor

bennor commented Jul 23, 2019

So definitely looks like our bug. IIRC RestEase was originally forked (or copied) from Refit by some people who wanted features we weren't prepared to add, so it's possible they inherited the same bug.

@bugproof
Copy link

bugproof commented Jul 24, 2019

I don't think it's a bug. Caller has to dispose HttpResponseMessage and that's it. Unless it deadlocks with custom response types.

https://github.com/reactiveui/refit/blob/master/Refit/RequestBuilderImplementation.cs#L253-L261

#332

@canton7
Copy link

canton7 commented Dec 27, 2020

IIRC RestEase was originally forked (or copied) from Refit by some people who wanted features we weren't prepared to add, so it's possible they inherited the same bug.

Just to set the record straight: RestEase is inspired by Refit (I liked the way of declaring an interface to represent an API), but is a ground-up project: there's no shared code, it's not a fork, and I've never read the Refit source. I wrote it because the stubs generation in Refit kept breaking, and writing something that used S.R.E. sounded like a fun weekend project. It kind of snowballed from there.

@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
Projects
None yet
Development

No branches or pull requests

6 participants