Instantiate the AsyncHttpClient lazily #118
Conversation
This is to fix the resource leak caused by creating a new client in `configure` and not shutting down the old one. Instantiating a singleton client was a problem because (by definition of being a singleton) it might be shared between multiple `Http` instances, meaning it's hard to know when you can/should shut it down. Got around the problem by making `Http` hold a config builder and a `lazy val client`. It's still possible to leak an `AsyncHttpClient` instance by making requests and then calling `configure` later, but I think people are less likely to do that. The normal use case is to configure your client at application startup and then start making requests.
|
Not sure why Travis failed. Tests pass on my machine. |
|
I checked the your Travis log, everything looks good. I think it is a Travis issue. I saw there are a few Travis related commits. Could you please rebase your commits on those commits, and try again? This hidden instance is really bugging me. |
|
I could rebase, but there has been no activity on this repo for a year. I think this project is dead. |
|
Err~I kinda sense that. But if you google "scala async http client", On Mon, Aug 22, 2016 at 9:40 PM Chris Birchall notifications@github.com
Thanks, |
|
Is this going to be merged? |
|
@mateusduboli Are you needing this patch? It's fixing a bug in 0.11.3, but isn't a bug in version 0.11.2. |
|
@ashawley I compared the two versions and the only thing that could be pointed as a relevant reason for this to not be present in 0.11.2 is the version of Is that the problem that causes the leakage of clients? |
|
@mateusduboli Yes, exactly. Here was the discussion on the dispatch mailing list |
|
LGTM. I've cherry-picked this into pull request #139 . |
|
This will fix 0.11.3 and 0.12.0 as well as fixing 0.13. |
|
@farmdawgnation AFAIK this is now merged / superseded by the AHC 2.0 update. |
|
Acknowledged, closing. |
This is to fix the resource leak caused by creating a new client in
configureand not shutting down the old one.Instantiating a singleton client was a problem because (by definition of
being a singleton) it might be shared between multiple
Httpinstances,meaning it's hard to know when you can/should shut it down.
Got around the problem by making
Httphold a config builder and alazy val client.It's still possible to leak an
AsyncHttpClientinstance by makingrequests and then calling
configurelater, but I think people are lesslikely to do that. The normal use case is to configure your client at
application startup and then start making requests.