https://bz.apache.org/bugzilla/show_bug.cgi?id=57804
Rainer Jung <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WORKSFORME |--- Status|RESOLVED |REOPENED --- Comment #3 from Rainer Jung <[email protected]> --- I just ran into the same problem and did a little analysis: It happens with the HC4 sampler (don't know about the others) when used with client certs. HC4 uses a pool that compares two things to find an adequate connection: the HttpRoute (target host, proxies etc.) and a "state" Object. If the state Object is null, then HC4 will only return a connection who's state is also null. If it is not null, the state of the connection must have the same state value. Now state is not something like closed or opened or so. Instead by default if no state is present, HC4 determines a state at the end of the request using a UserTokenHandler. The default UserTokenHandler will set the state of a connection at the end of the request to the value of the client cert used in the SSL session. But JMeter always requests a connection with null state value, so a previously used connection will never match, I don't have a fix ready, but since currently the requested state - null - and the state a connection is set to after use - the client cert - never matches, we either need to make sure, that we request a connection for the correct state, or that the state of a connection is not set or set to a stete we use when requesting the connection. Example: Set the state to something sensible before running the request: the state can be injected using localContext.setAttribute(ClientContext.USER_TOKEN, "dummy"); in JMeter HTTPHC4Impl between creating localContext and calling executeRequest(). HC4 will then take the state from the context and not try to determine it using the SSL Session. For the first request, a new connection has to be created and when it is released is will be branded using the provided state. Next time we need a connection, if we ask for the same state, we will get the same connection back. So if we have a good concept of the correct state Object, we could fix it that way. So far for now. -- You are receiving this mail because: You are the assignee for the bug.
