@@ -85,9 +85,9 @@ See :doc:`/plugins/introduction`
85
85
HttpClientPool
86
86
--------------
87
87
88
- This kind of client allows to send a request on a pool of ``HttpClient `` and/or ``HttpAsyncClient`̀ `.
88
+ This kind of client allows to send a request on a pool of ``HttpClient `` and/or ``HttpAsyncClient ``.
89
89
90
- You can attach http clients to this kind of client by using the ``addHttpClient `` method::
90
+ You can attach HTTP clients to this kind of client by using the ``addHttpClient `` method::
91
91
92
92
use Http\Client\Common\HttpClientPool\LeastUsedClientPool;
93
93
use Http\Discovery\HttpAsyncClientDiscovery;
@@ -107,13 +107,13 @@ You can attach http clients to this kind of client by using the ``addHttpClient`
107
107
108
108
Using this kind of client is useful is some use cases :
109
109
110
- - When using a cluster (like a elasticsearch service with multiple master nodes)
110
+ - When using a cluster (like a Elasticsearch service with multiple master nodes)
111
111
- When you want to use fallback servers with the combination of the ``RetryPlugin `` (see :doc: `/plugins/retry `)
112
112
113
113
Each added client will be decorated by the ``HttpClientPoolItem `` class unless it's already an instance of this class.
114
114
It allows the pool to be aware of the number processing requests in real time, and also deactivate a client on a error,
115
- it will be reenable automatically after a certain amount of time. However this behavior is not enabled by default (it
116
- reenable after 0 second, so after each request), but you can enable this behavior, client by client by directly using
115
+ it will be reactivate automatically after a certain amount of time. However this behavior is not enable by default (it
116
+ reactivate after 0 second, so after each request), but you can enable this behavior, client by client by directly using
117
117
the ``HttpClientPoolItem `` class::
118
118
119
119
// Reenable after 30 seconds
@@ -130,13 +130,13 @@ LeastUsedClientPool
130
130
``LeastUsedClientPool `` choose the client with less processing request in the pool. As it sounds the best strategy for
131
131
sending a request on a pool of clients, the current implementation have some flaws :
132
132
133
- - The counter is not shared between php process, so this strategy is not so useful in a web context, however it will make
134
- better sense in a php command line context.
133
+ - The counter is not shared between PHP process, so this strategy is not so useful in a web context, however it will make
134
+ better sense in a PHP command line context.
135
135
- The counter of a request is decremented after each client call, so using this with the ``sendRequest `` method is
136
136
useless, as the first client will always be at 0 after each call. It's better to use the async mechanism, with the
137
137
``sendAsyncRequest `` method to correctly distribute requests across your pool.
138
138
139
- A disabled client will be remove for the pool until it is reenable , if none are available it will throw a
139
+ A deactivated client will be removed for the pool until it is reactivated , if none are available it will throw a
140
140
``NotFoundHttpClientException`̀`
141
141
142
142
RoundRobinClientPool
0 commit comments