sebb wrote:
We are using HttpClient in Apache JMeter.
This uses multiple threads to simulate multiple users.
We don't use HttpClient and a Connection Manager, as we specifically
don't want to share connections between threads. Instead, we create
our own HttpConnection objects and pass these to
method.execute(state.connection).
I'm now wondering whether this is a sensible approach?
Sebastian,
This approach works more or less ok with HttpClient 2.0.x due to the
fact that in HttpClient 2.0 almost all control logic is stuck in the
HttpMethodBase class. HttpClient 3.0 has a slightly saner design
compared to that of HttpClient 2.0. The authentication, redirect
handling, request retry handling logic has been moved from
HttpMethodBase to HttpMethodDirector in HttpClient 3.0. Therefore, if
you want to continue using HttpConnection and HttpMethod classes
directly, you face the prospect of having to re-implement all this logic
in JMeter.
Perhaps we are missing out by not using a method such as:
httpClient.executeMethod(method)
I would have expected the two approaches to be much the same, but on
looking at the latter, this is handled via HttpMethodDirector, which
seems to do rather more than method.execute() does.
Should we be using a customised ConnectionManager instead?
I agree with Roland that in your case the simple HTTP connection manager
should suffice. This said, there's no harm in writing your own
connection manager if you want to exercise more control over the way
connections are handled.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
