-
Bug
-
Resolution: Deployed
-
Medium
-
2.8
-
None
-
None
In OnDemand, the Crowd Base URL is configured as http://localhost/crowd/service/
During RestExecutor initialisation the maximum connections per route is configured for the route "http://localhost" to be 20. There's a subtle problem with this though. When actually issuing a request to Horde, the HttpRoute becomes "http://localhost:80", which is treated differently, and falls back to the default maximum connections per route of 2.
It looks like INST-2 introduced this issue, when they updated the Icebat to explicitly hack the CROWD_SERVER_BASE_URL in each services run file. /cc cchauvet
Ultimately this looks like it might actually be an Apache HttpClient bug. In debugging I noticed that the outbound request is definitely "http://localhost/crowd/foo", but after it passes through all the various HttpClient "*Exec" steps it ends up as "http://localhost:80/crowd/foo".
- causes
-
-
- Closed
-
- is caused by
-
CWD-2942 Replace commons-httpclient with Apache HttpComponents
- Closed
- is related to
-
-
- Closed
-
-
![[JIRA Server (Bulldog)]](/images/icons/generic_link_16.png "[JIRA Server (Bulldog)]")
KRAK-256
You do not have permission to view this issue
- was split into
-
-
- Closed
-
- links to
[CWD-4096] RestCrowdClient http.max.connections doesn't take effect when the base URL doesn't include a port
This is still reproducible in Crowd 2.8.2 for https URLs: https://jira.atlassian.com/browse/STASH-7081?focusedCommentId=729448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-729448
HTTPCLIENT-1575, fixed upstream, will normalise HttpRoute instances to include a specific port (for now) and throw an IllegalArgumentException (in 5.0). The existing fix in Crowd (filling in the port in RestExecutor.routeFor) will continue to work with both implementations.
It would be very easy to apply this workaround in code and always pass in an HttpRoute with the port resolved against DefaultSchemePortResolver.INSTANCE. But yes, this looks like a bug in HttpClient, or at least an underspecification of what PoolingHttpClientConnectionManager.setMaxPerRoute should do when passed an HttpRoute with port of -1.
Good find!
A workaround exists, explicitly set your base URL to http://localhost:80
To be clear on the cause and effect: if I create a RestExecutor with a base URL of http://localhost and a connections-per-route of twenty, I'll actually get a pool size of two?
I think this is a bug in HttpClient itself. I'll raise something upstream.
The URL used by a RestExecutor should be consistent. That is, it's constructed with a base URL and then all requests use the same one. If there's a base URL that doesn't behave like that, that would be a bug. And if there's a URL that pooling doesn't work with at all, that would also be a bug.
Looks like you've already investigated here; can you see which case it is, or reduce this to a test of RestExecutor?
Per request from jwalton, the patch will be applied under a new issue:
CWD-4337