[
https://issues.apache.org/jira/browse/HTTPCLIENT-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423498#comment-17423498
]
Anurag Agarwal commented on HTTPCLIENT-2180:
--------------------------------------------
So I browsed through the code and figured there is no easy way to use the
AsyncConnExec and InternalAsyncExecRuntime. I stumbled upon 2 more approaches:
Approach 1 (Long Term):
In this approach we can make another implementation of the client, whose job is
just to warm the connection.
User would give the connection manager instance to the client and give the same
instance to their original client.
The connection manager that this can accept is going to be
PoolingConnectionManager only, so that we can have more type safety
and the user should not be able to make mistake of passing generic connection
manager to this client.
This client would handle the process of creating a connection and storing it
within the pool, we will need to reimplement a lot of
code and refactor to segregate the connection making process with the request
execution process that this client can handle.
One can think this to be not a client but more of wrapper classes, like it has
been done for the httpcomponents-cache layer.
The connection manager would have a ready method which will be considered done
when the connection pool is initialised after which the
actual client can may be proceed with sending requests or make itself ready.
Since the connection manager is shared, this new client will actually release
all the endpoints after all the initial warmed up requests
are executed.
Approach 2 (Quick & Easy):
So given that a lot of things come in picture when we are to make connection to
an external endpoint and one would need all of them to
be incorporated for different use cases, as suggested earlier we can plan on
sending cheap HttpRequests like OPTIONS / HEAD to this routes.
The issue in the given approach was that since we are using a connection pool
which would try to keep as minimum number of connections as
possible, it would try to use the re-use the connections and we will not have a
way to get the desired number of connections from the
external service.
This problem exists because we try to either get an available entry, if we turn
the functionality off for the warm-up time to get the
available entry even when it is available, we will always try to lease a new
request by making a new entry. This will even be applicable
only for connection pools and once we turn off the mode the available entries
will be readily available for the client to use.
In this approach we would simply require the getAvailableEntry method to return
false when the warm up mode is enabled for both
Lax and Strict connection pool and then we can control the behaviour from our
clients to enable / disable it.
> Pre-init minimum number of connections
> --------------------------------------
>
> Key: HTTPCLIENT-2180
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2180
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient (async), HttpClient (classic)
> Reporter: Anurag Agarwal
> Priority: Minor
> Labels: volunteers-wanted
> Fix For: Future
>
>
> Most of the applications suffer from a problem of cold start where we don't
> have connections created at the start of the application and thus the first
> few requests suffer by making a lot of connections.
> During deployment this can even pile up a lot of not completed request and
> may lead to losses.
> One suggestion I had in mind is to create few connections before the
> application has begun from the intended endpoints.
> Also sometimes the nautre of your traffic can be spiky in which scenario
> opening and closing a lot of connections also doesn't make sense.
>
> These can be solved with either or both of the suggestions:
> # Have a minConnectionPerHost policy in connection pool which won't let
> connection pool for a host to go below this number or make a new connection
> when it does. At the start of the http client these minimum connections will
> be created to the end services.
> # Provide an easy mechanism for use to create connections via
> ConnectionManager. Currently in PoolingAsyncConnectionManager one must give
> ConnectionInitiator which make it difficult to directly use the connection
> manager to create connections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
