Hello,

My problem with MaxTotalConnections is the following. My application is
similar to a proxy. The user enters a set of rules and, through these
rules, my application decides the number of simultaneous requests that it
allows to pass to the app servers. And this is done modifying dinamically
the maxTotalConnections attribute (as I done with HttpClient 3). If
HttpClient 4 cannot modify this attribute dinamically, it'll be impossible
for me to migrate from H3 to H4.

Fortunately, I've seen that Oleg has opened a new issue to add this
functionality to H4 B3. I don't know the opinion of other users, but for
me it's essential. For the moment, I'll move back to H3.

Thanks for all,

Joan.

> sebb wrote:
>> On 06/02/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
>>> Joan Balagueró wrote:
>>>
>>>> Thanks Oleg. It seems strange to me because HttpClient3 (sending
>>>> requests
>>> to
>>>> the same server) never fails. I'll take a look at the code again and
>>>> I'll
>>>> comment you something else.
>>>>
>>>>
>>>  I do not know why the server chokes on packets generated by HttpClient
>>> 4,
>>> but this is clearly a server side problem. The server should return a
>>> non
>>> 2xx response if something is not okay, not just drop the connection.
>>>
>>>  HTTP/1.0 can be a problem or absence of User-Agent header. Whatever.
>>> At any
>>> rate the server is broken.
>>>
>>>
>>>
>>>> Just another question. When I modify a connection or response timeout
>>>> setting another value (for example, from 5000 to 2000) HttpClient4
>>>> applies
>>>> this new value correctly (as expected, obviously). But not the same
>>>> with
>>>> maxConnections. If I set MaxConnections from 100 to 1 using
>>>> ConnManagerParams.setMaxTotalConnections, then:
>>>>
>>>> DefaultHttpClient object --> DefaultParams --> parameters -->
>>>> http.conn-manager.max-total=1 --> OK!
>>>>
>>>> But DefaultHttpClient object --> connManager --> connectionPool -->
>>>> maxTotalConnections still to 100 --> BAD!
>>>>
>>>> And if I send 50 simultaneous request, HttpClient processes all of
>>>> them
>>> even
>>>> with maxTotalConnections to 1.
>>>>
>>>> Is this a bug? Or after
>>> "ConnManagerParams.setMaxTotalConnections" I must
>>>> set the new "param" values to the HttpClient object with
>>>> "this.objHttp.setParams(set the "params" object with the new value of
>>>> MaxConnections)"?
>>>>
>>>>
>>>  This happens because the connection manager does not reset the
>>> existing
>>> connection pools for established routes. One can see this as a bug or a
>>> 'feature' as one can look at it from different perspectives. To me this
>>> is
>>> an expected behavior. MaxTotalConnections parameter is expected to be
>>> set at
>>> the start up time and to not mutate afterwards.
>>
>> Maybe this could be added to the Javadoc?
>>
>
> Opened a JIRA for this issue
>
> https://issues.apache.org/jira/browse/HTTPCLIENT-823
>
> Oleg
>
>>>  Oleg
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> Joan.
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail:
>>> httpclient-users-unsubscr...@hc.apache.org
>>>  For additional commands, e-mail:
>>> httpclient-users-h...@hc.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to