singleton httpclient

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

singleton httpclient

Jim Fox

I'm curious why the HttpClient (v3.4) is implemented as a
singleton, rather than, say, from a PoolingHttpClientConnectionManager.

It seems that the singleton client can be kept open, reducing connection
build and destroy overhead, but it also single threads all requests.  With
a pooling connectin manager we could have more than one always open
client.

In addition, there is a setting (which is clearly not supposed to be changed) that
undoes the singleton approach.  This however would seem to create a great
many open connections, as a user of the httpclient will not be closing it.

Thanks,

Jim
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Cantor, Scott E.
On 11/18/19, 2:39 PM, "dev on behalf of Jim Fox" <[hidden email] on behalf of [hidden email]> wrote:

> I'm curious why the HttpClient (v3.4) is implemented as a
> singleton, rather than, say, from a PoolingHttpClientConnectionManager.

Brent would know better than I, but I don't think it is. We don't install our own ConnectionManager from what I can see, which means it auto-installs a PoolingHttpClientConnectionManager, and that's why the builder we have exposes properties like max connections and max per-route.

It's all a bit spaghetti, but that's how it read to me. I think I've tested that in the past and certainly seen it operate multiple connections at a time.

The TLS layer adds a lot of complexity to what we're doing, but I think all that is being done outside the scope of actually overriding its connection manager.

Note that all the components themselves by design should operate on HttpClient, so they don't assume anything, and there are no actual concrete beans that should ever be used for any clients of your own (that was a screw up on our part, the built-in clients in the system files are actually a source of a ton of Spring bugs that screw up service reloads as it turns out).

So in theory you can do anything you want.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Jim Fox


>> I'm curious why the HttpClient (v3.4) is implemented as a
>> singleton, rather than, say, from a PoolingHttpClientConnectionManager.
>
> Brent would know better than I, but I don't think it is. We don't install our own ConnectionManager from what I can see, which means it auto-installs a PoolingHttpClientConnectionManager, and that's why the builder we have exposes properties like max connections and max per-route.
>
> It's all a bit spaghetti, but that's how it read to me. I think I've tested that in the past and certainly seen it operate multiple connections at a time.
>

If there is a PoolingHttpClientConnectionManager somewhere on that plate of spaghetti, how do I control the min and max connection limits?

Jim
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Cantor, Scott E.
On 11/18/19, 4:12 PM, "dev on behalf of Jim Fox" <[hidden email] on behalf of [hidden email]> wrote:

> If there is a PoolingHttpClientConnectionManager somewhere on that plate of spaghetti, how do I control the min
> and max connection limits?

If there are settings other than maxConnectionsTotal and maxConnectionsPerRoute they're probably not exposed. The builder is there to make Spring config more friendly but it's got a lot of known gaps. But those two are definitely there.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Brent Putman
In reply to this post by Cantor, Scott E.


On 11/18/19 4:03 PM, Cantor, Scott wrote:
On 11/18/19, 2:39 PM, "dev on behalf of Jim Fox" [hidden email] wrote:

I'm curious why the HttpClient (v3.4) is implemented as a 
singleton, rather than, say, from a PoolingHttpClientConnectionManager.
Brent would know better than I, but I don't think it is. We don't install our own ConnectionManager from what I can see, which means it auto-installs a PoolingHttpClientConnectionManager, and that's why the builder we have exposes properties like max connections and max per-route.

It's all a bit spaghetti, but that's how it read to me. I think I've tested that in the past and certainly seen it operate multiple connections at a time.


Yes, that's correct as far as I know.  The Apache builder, which our builder wraps, defaults to a PoolingHttpClientConnectionManager, so that's what you get by default.



The TLS layer adds a lot of complexity to what we're doing, but I think all that is being done outside the scope of actually overriding its connection manager.


Yes, I don't think that changes the connection manager you get, just the TLS socket factory.  So you'll still get the pooling conn mgr.



--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Brent Putman
In reply to this post by Cantor, Scott E.


On 11/18/19 4:22 PM, Cantor, Scott wrote:
On 11/18/19, 4:12 PM, "dev on behalf of Jim Fox" [hidden email] wrote:

If there is a PoolingHttpClientConnectionManager somewhere on that plate of spaghetti, how do I control the min
and max connection limits?
If there are settings other than maxConnectionsTotal and maxConnectionsPerRoute they're probably not exposed. The builder is there to make Spring config more friendly but it's got a lot of known gaps. But those two are definitely there.

Right, our client builder seeks to must make it Spring-friendly for the most common options.

Our builder wraps an instance of the Apache builder.  There's a no-arg ctor of our builder which gives you a default Apache one, but there's also one which allows injection of a custom-configured one:

 public HttpClientBuilder(@Nonnull final org.apache.http.impl.client.HttpClientBuilder builder) { ... }

So using that variant, you could wire up literally anything that is possible via the Apache builder.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Jim Fox
In reply to this post by Brent Putman

>
> Brent would know better than I, but I don't think it is. We don't install our own ConnectionManager from what I can see, which means it auto-insta
> lls a PoolingHttpClientConnectionManager, and that's why the builder we have exposes properties like max connections and max per-route.
>
> It's all a bit spaghetti, but that's how it read to me. I think I've tested that in the past and certainly seen it operate multiple connections at
>  a time.
>
>
> Yes, that's correct as far as I know.  The Apache builder, which our builder wraps, defaults to a PoolingHttpClientConnectionManager, so that's
> what you get by default.
>
Possibly I was confused by the code in .../ext/spring/factory/HttpClientFactoryBean.java, which seemd to indicate that the HttpClient was a singleton.  Is that something of a distraction?
In any case I see the configurations for max clients.

Thanks,

Jim
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: singleton httpclient

Cantor, Scott E.
On 11/18/19, 4:40 PM, "Jim Fox" <[hidden email]> wrote:

> Possibly I was confused by the code in .../ext/spring/factory/HttpClientFactoryBean.java, which seemd to indicate
> that the HttpClient was a singleton.  Is that something of a distraction?

The bean it produces is a singleton (one client), but it internally has a pooling manager, and is safe to use across threads or components, up to a point.

There's a bug in Spring with parent beans that manifests when you have parent/child Spring contexts, and causes our service reloading to fail. So if you directly inherit from or use that one bean defined up top in a connector in the resolver, for example, things start breaking if you reload the resolver.

As long as you directly create your own copy of the factory bean definition to do what you need done, it all works fine, but it isn't a single connection at a time in either case even though the beans themselves are singletons. As you probably were seeing, you do *not* want to use prototype, it's not meant to be used that way.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]